The two project solution

time to read 2 min | 250 words

Back to technical content :-)

This post from Kyle Baley got me thinking about my last few projects. In them, I trended toward the assembly per logical layer of the app. So I had things like:

  • MyApp.Model
  • MyApp.Web
  • MyApp.Services
  • MyApp.Infrastructure
  • MyApp.Tests

It worked, but at one point I found myself managing 18 projects solutions, and that was only because I was committed to reducing the number (otherwise it would have been much higher). I hear about people talking about 30 - 60 projects in a single solution, and there are people with more. Considering the cost of just managing that (not to mention the cost for compilation per project), that sounds like a very bad approach.

Right now, I think that on the next project I'll have the following structure:

  • MyApp
    • /Model
    • /Web
    • /Services
    • /Infrastructure
  • MyApp.Tests

Everything that the application does will be in a single project, without the need to split it off to a lot of separate projects. I found that the vaunted isolation that we seem to seek is achievable easily without forcing artificial barriers between the different parts of the application. It also means shorter compilation times and easier deployment mode.

More than everything else, it means that I have less noise to deal with.

I would extend that to an assembly per physical location, so assuming that I had a smart client application, I would use the following scheme:

  • MyApp.Server
  • MyApp.Interfaces
  • MyApp.Client
  • MyApp.Tests

And that would be it.