locked
MVC best practice: File structure RRS feed

  • Question

  • User-282271646 posted

    I have now watched most of the tutorial videos on ASP .NET MVC, I have looked through the NerdDinner application and followed the video series on MVC Storefront.

    Im a little confused since all of the tutorials and projects go different ways in creating structure in the solution. I can see that for smaller projects it would be okay to have all the subfolders (Models, Controllers and Views) in the same project inside a VisualStudio solution. But what about a bigger project, what is the best practice?

    I would love to hear how you all organize your solutions, do you have one project for "Test", one project for "DataAccess" and one for "Web"?

    Monday, July 13, 2009 6:02 AM

Answers

  • User-2004887772 posted

     It's generally agreed that the domain model should go in its own project (so, Model).  Whether data access is separate from that or part of it depends a bit on your preference of pattern and how likely it is to need to swap out the persistence logic.  Personally, I often find myself making a Web project, Test project, Model project (which includes interfaces for all the repositories I'll need, but not implementation) and a Data project that just implements all the repositories.  I also have a Utils project that's used in most of my solutions that has a bunch of reusable things like helpters, action filters, controller base classes, etc.

    All that said, I don't follow that structure dogmatically.  The rule of thumb that I like from Evans (Eric Evans, Domain Driven Design) is that you should organize your packages along lines of what's likely to change at the same time.  I've found that to be a pretty good guiding thought.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 13, 2009 7:07 AM

All replies

  • User-2004887772 posted

     It's generally agreed that the domain model should go in its own project (so, Model).  Whether data access is separate from that or part of it depends a bit on your preference of pattern and how likely it is to need to swap out the persistence logic.  Personally, I often find myself making a Web project, Test project, Model project (which includes interfaces for all the repositories I'll need, but not implementation) and a Data project that just implements all the repositories.  I also have a Utils project that's used in most of my solutions that has a bunch of reusable things like helpters, action filters, controller base classes, etc.

    All that said, I don't follow that structure dogmatically.  The rule of thumb that I like from Evans (Eric Evans, Domain Driven Design) is that you should organize your packages along lines of what's likely to change at the same time.  I've found that to be a pretty good guiding thought.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 13, 2009 7:07 AM
  • User-282271646 posted

    Thanks for a very good answer, think I am on the right track now.

    By that way, are there any books or resources you recommend by Eric Evans or others on the subject of Domain Driven Design?

    Monday, July 13, 2009 8:11 AM
  • User-2004887772 posted

     I started a list like that here:  http://forums.asp.net/t/1439080.aspx  but it didn't really take off.  Hope you find what is there useful.  Evans and Nilsson are pertty much the Gods of DDD in my book.

    Tuesday, July 14, 2009 5:39 PM