2

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.

Improve this question
3

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

Improve this answer
2
  • In principle there is nothing wrong in having 70 in a single solution. Its just our first generation Core 2 Duo computers can't handle them and VS really starts crawling. – mob1lejunkie Jun 6 '11 at 12:27
  • Indeed, we've had similar issues here, I think 70 projects is madness personally and would question whether a) they are necessary or if so, then b) whether they need to be in the same solution. – Mantorok Jun 6 '11 at 12:34
0

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.

Improve this answer
2
  • Wouldn't you agree that having everything in separate projects forces separation of concern and automatically guards against tight coupling? – mob1lejunkie Jun 6 '11 at 13:27
  • I do agree :) --- but that does not mean one cannot get the same with fewer projects. If it doesn't buy you much then it becomes personal/team preference. – user23356 Jun 7 '11 at 4:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.