Solution organisation

Question

I have been working on asp.net applications for 6 years but almost all of it has been extending and maintaining existing applications. I now have the need to develop a new application and I am scratching my head :(

There is a lot of material on Software Design principles and patterns but not much content on organisation. Should the various layers be in separate namespaces, folders or projects?

I do have plan to create WCF in future so having Service layer as project makes sense but I am unsure of how many projects I should have? By default, MVC 3 web site has Models and Controllers in the same project does it make sense to separate them to different projects?

I would be very very appreciative if someone can post screen shot of well organised MVC 3 solution.

I understand this probably depends on personal preference and project size but I need some kind of guidance. Our main application has over 70 projects in a mammoth solution...Please help me avoid this.

Many thanks.

Answer 1

Some would say that 70 projects is not unreasonable, however my approach has always been to seperate out to projects that which is likely to be used by more than 1 other project.

There is no right and wrong in this situation, however I've seen people seperate out code into projects with little value, so do it when it makes sense, after all, you could seperate code out into seperate folders (and namespaces), and don't forget that seperating code into a seperate project is, what, a 10 minute job?

I would say that for an MVC project it would be good practice to seperate out your Model layer into a seperate project, because persistence layers should never, IMO, be absorbed into any View (UI) project. You could also do the same for the Controller layer, it won't hurt to have 3 projects to begin with, but it would be quite unlikely that the Controller layer would be re-used, I always felt that View & Controller were most of time quite tightly bound, where-as your Model layer could be re-used by another website, windows or console application for example.

My 0.02p

Answer 2

I tend to place UI code in a separate assembly. So there would be an MVC or Web or Win assembly depending on my implementation. The shared bit of the solution I would place in a separate assembly. I would only divide that further if it is really necessary; else I just use folders.

Separating out the data access may be necessary if you end up using another data store type. But, once again, I would only do that once it is required.

No real need to separate out Models or Controllers. For a plug-in architecture you could look at placing Controllers / Models / Views in separate assemblies but that would require some thinking.

The only thing one would need to guard against is tight coupling when everything is in the same assembly since everything is reachable.