Home » .NET WPF » .NET WPF Project Solution Structure

.NET WPF Project Solution Structure

January 3rd, 2011 Leave a comment Go to comments

I’m currently at the start of developing a fairly sizable project in .NET using C# with WPF.  As this is going to be quite a large project I thought it would be prudent to spend a bit of time upfront to organise it into some sort of a sensible structure which will see us through into the future, so that we don’t have to change it half way because things get too messy.  So I set out to find the appropriate solution structure for a WPF project.  A bit of googling turned up a few posts such as Recommended WPF Project Structure discussion on StackOverflow and WPF Project Structure by Dr. WPF, but neither gave a difinitive answers or detailed Pros and Cons of any particular structure.  So taking what I’ve read and my own experience my analysis is as follows…

There are ultimately two ways to really structure your project… These are by Resource Type and By Functionality or some sort of a blend/combination of the two… Each has it’s own benefits and drawbacks, which I’m going to discuss here.  The post by Dr. WPF I mentioned above covers some of the other aspects such as making sure your folder structure and your namespaces match up and that you keep to one class per file and name them the same.  I take all of these best practices as a given and something that should be followed as gospel in any .NET, WPF or any other project or programming language for that matter.  What I’m concerned with is purely the options for organising the project structure while following these best practices.

Organising by resource type basically means that you organise by Resource Type FIRST and THEN by Functionality.  For example, if you were building a typical CRM/ERP system you might have functionality such as Customers, Suppliers, Product Categories, Manufacturers, Orders and so on.  In the case of organising by Resource Type first you might have a structure something like this:

-Data
-Windows
–Customers
–Suppliers
–Orders
–etc…
-UserControls
–Customers
–Suppliers
–Orders
–etc…
-Controls
-Models
-etc…

OR perhaps:

-Data
– UI
–Controls
–Windows
—Customers
—Suppliers
—Orders
—etc…
–UserControls
—Customers
—Suppliers
—Orders
—etc…
–etc…
-Models
-etc…

Generally this should work fairly well and is indeed how many projects are organised.  Obviously, you’d have other folders like Resources, maybe Models (depending on whether you have one project or many within your solution) and so on.  One drawback is that if you’re working with Customers you will need to jump between two higher level folders and that can be quite annoying.

So, the second option is to organise by Functionality first, so you might have:
-Common
–Controls
–Resources
-Customers
–UserControls
–Windows
-Suppliers
–UserControls
–Windows
-Orders
–UserControls
–Windows

This however is also not all that great if you’ve only got a single project within your solution as you’d need to put your Business Logic Layer (BLL) / Data Access Layer (DAL) into the Functionality and sometimes this isn’t even possible when you’re using .NET Entity Framework as you’ll often have more than one entity in the one file and it would too much of a pain to do it any other way.  Based on this you certainly come to the conclusion that organising purely by Functionality first isn’t going to work particularly well, so what you really need is either purely the first approach (i.e. organising by Resource Type first) or a combination of the two approaches.

Using a combination of the two approaches you would end up with a directory structure something like this:
-Data
-UI
–Common
—Controls
—etc…
–Customers
—UserControls
—Windows
—etc…
–Suppliers
—UserControls
—Windows
—etc…
–Orders
—UserControls
—Windows
—etc…
–etc…
-Models
-etc…

OR, if you have relatively simple functionality, you may not need to further break down the functionality by resource and your structure would look like this:

-Data
-UI
–Common
–Customers
–Suppliers
–Orders
–etc…
-Models
-etc…

If your project is even smaller you may do something like this and just have all your functionality files directly within Resource Type folders:
-Data
-UI
–Controls
–Windows
–UserControls
-Models

If your project absolutely tiny you might just do:
-Data
-UI
-Models

Or if it’s just some basic proof of concept you might even consider putting everything in the project directory itself.

The one thing I probably wouldn’t do for larger projects is structure by resource type to a very deep level before switching to structuring by functionality, as it gets very annoying if your Windows and User Controls are located completely separately from each other.

I would also recommend that if you envisage a relatively large application that you split your solution by layer into projects (e.g. App.UI and App.Models or say App.BLL).  If you need multiple projects of similar functionality (e.g. some Providers) you should also consider grouping these together using a Solution folder.

Now, an important thing to note here is that ultimately it doesn’t matter whether you’re structuring a WPF Project, an ASP.NET Project or any other project in any other programming language for that matter.  Ultimately your project structure will depend on compexity, but as a general rule of thumb you should structure by Resource Type first (The resource type may be its own project within the solution) and then either by Resource again or by Functionality.

Generally it is also a bad idea to mix contextually different things at the same level… For example it’s a bad idea to do this:
-Customers
-Orders
-Products
-Controls

This is confusing as Customers, Orders and Products are types of functionality while Controls is a Resource Type.  If you do things this way it will get confusing.  It may however be OK to put individual files directly in the folder together with subfolders organised By Resource Type.  For example, for a small ASP.NET application you might put all the .aspx pages at the root of the project and then have Controls, Modules, MasterPages, etc, underneath the root folder as well.  Sometimes people would also put say Administration and Install (which are really functionality related folders at the same level) (e.g. NopCommerce does it this way).  I don’t necessarily agree with this approach and would recommend you don’t do it, but the important thing is to make sure things still make sense for you and other developers in the long run.

For smaller projects it may also not be needed to break down the structure further than what is necessary to make sense.  For example, if you’re organising by Resource Type then by Functionality (e.g. UI->Customers) there may not be a need to introduce the next level (i.e. UI->Customers->Windows and UI->Customers->UserControls) if you don’t have all that many Windows and User Contr0ls.  Likewise there is not always a need to break down your structure by functionality after breaking it down by Resource Type.  For example:
-UI
-Models

or perhaps

-Windows
-UserControls
-Models

This kind of structure can work quite well if your functionality is relatively limited and there is little point creating a massive directory structure.  Ultimately, what you’re trying to facilitate, is ease of navigation and locating of files within your project.  That is indeed the whole purpose of having a project structure.  So, ultimately, your project/solution structure needs to reflect the size of your solution, which is why there is no one single way of doing things.  Aimed with some of the reasoning and analysis presented here you should be well equipped to make a decision at to how to structure your own project, whatever that may be.

Share
Categories: .NET WPF Tags:
  1. No comments yet.
  1. No trackbacks yet.


one + 3 =