VS Solution Folder Structure

[Howard van Rooijen]

Hi,

There were a couple of conversations around solution structure / TreeSurgeon - on a slight tangent - one of the conventions I'm trying to get various internal teams to adopt is a Visual Studio solution folder structure containing some DDD style concept names:

Solution ‘MyApp’
+---Data
|   +---Visual Studio 2008 Database GDR Project files (do not build in debug mode)
+---Deployment
|   +---WiX Installer Projects for deploying “Presentation” projects (do not build in debug mode)
+---Domain
|   +---MyApp.Domain.* Projects (contains core contracts + domain entities + specifications)
+---Framework
|   +---MyApp.Core.* (any projects with cross cutting concerns, caching, logging, utils etc)
+---Infrastructure
|   +---MyApp.Infrastructure.* (repositories / integration points live here)
+---Presentation
|   +---MyApp.Web, MyApp.Web.Controllers, MyApp.WCFEndpoints
\---Services
    +---MyApp.Services, MyApp.Management.Services

N.B. MyApp.Management.Services is a system management API layer, that is generally wrapped in a WCF Service and consumed by PowerShell Commandlets / MMC SnapIn.

It may be slightly pedantic (our projects do tend to be quite large), but it makes my code OCD happy and provides a few high level DDD concepts and offers some familiarity / consistency for developers moving between projects.

This also ties into another experiment of trying to get devs to create architectural whiteboard sketches in the style of Onion / Hexagonal Architecture to help them visualise the solution (and external dependancies) in a non N-Tiered way, then carrying those concepts through to the VS Solution.

/Howard

[Kyle Baley]

I've been trying to go the other way, with fewer projects. Basically, one for the app and one for tests if I can get away with it, and typically I can only for personal projects because no one else seems to have bought into it. It requires more discipline which is why I don't mind for personal projects, because I know I'm not going to access the data layer from my web project. In teams where you can't be certain, you can use NDepend to maintain boundaries.

Regardless if you use two projects or twenty, another thing to consider is that you don't have to deploy your project the same way you build it for development. Using an automated build tool, you don't have to compile your app into separate assemblies for Domain, Data, UI, etc. If they are all being deployed on the same server, why not compile them all into the same assembly for deployment? Unless you are actually re-using one of them in other projects, which is rarer than companies would like to think, there are benefits to having a single assembly per physical layer.

[Howard van Rooijen]

A few of our guys who went on the JP Boodhoo's "Nothin' But .NET" course came back with the same opinion. Managing bigger teams, with developers of all abilities is a different problem space entirely tho. Running NDepend with CQL queries in your build can allow you to add some rigour and stop people introducing silly dependencies. Otherwise you're down to trusting that people will (and know how) to do the right thing.

One thing about multiple assemblies I do like (and has saved me in the past) is being able to patch a production environment by dropping in a single assembly and modifying the bindingRedirect settings.

As for your second point - we have ILMerge in the Build & Deployment Process for that very reason! The lovely thing about the Fluent Registration in Windsor is that you can merge assemblies and not have to worry about the mapping files / references. Bliss!

Lots of the projects within the "Framework" folder are generally removed and introduced as libs after the first couple of sprints once the churn has calmed down a bit. The downside to having a large number of projects is the "CopyLocal = true" tax which can kill performance (see Patrick's analysis of this phenomena) - I'd much rather have all project building to a common folder. This would also solve the problem of having to include all references (or having a post build script to copy assemblies) into your "presentation" project so that your DI framework can resolve dependencies.

Part of the purpose of the structure, is to get people thinking about *what* they're developing and *where* it actually belongs. If you have all your code in an amorphous project - that can be a bit of a danger.

Interestingly - we don't separate out our tests into a separate project (except for maybe integration tests); we're doing BDD - we generally have a 1:1 pairing of Class to Spec, i.e. ProductController and ProductControllerSpec living side by side. It makes it very visually apparent when a class doesn't have any test coverage. If you want to be very OCD about it (I generally am) you can use the VSCommands 1.0 addin to "group" the two files together, so the Spec appears as a code-behind to the Class it's testing. Having Class and Spec living side by side means you can also create R# live templates to generate stubs for both classes then you can use R# to move them into different physical files.

/Howard