When to Add a Project to a Solution

To my knowledge there is not an official standard on when to add projects to a solution.

As a software consultant I’ve seen it done many ways. Below are the most common approaches to project structures.

By Namespace

One school of thought is each namespace gets a project. In most cases the projects don’t have any sub folders. This structure allows for simple project layouts. The downside is it can lead to solutions with 40, 50 or more projects.

By Separation of Concern (SOC)

Another school of thought is by SOC, for example a project for the UI layer, a project for the model (entities), a project the business logic and a project for the data layer. This allows for easy identification of the logical layers. The downside is SOC has nothing to do with assemblies. Just because the projects and the logic layers can be aligned does not mean they should.

Minimalist Approach

This school of thought keeps everything together until there is a reason to split it out. Reasons you’d want to split out code could be for testing or for using the code in another project.

In its extreme you’d have one project with the models and the data access together. The code would logically be broken up. SOP would be enforced by the architecture, not the project structure. The upside to this approach is the project structure is simple. You’ll have 2 to 4 projects in a solution. The downside is that it’s the responsibility of the developer to enforce SOP.

Which approach do I use?

I follow the Minimalist Approach.  Identifying SOC is hard. The Minimalist approach is not for the faint of heart. Those whom don’t have a concrete grasp on SOC will be better served aligning SOC and the project structure. This ensures there will be no cyclical references and SOC.