ASP.net MVC project structure
I've written a couple of (small) sites and simply stuck with the same structure that NerdDinner had and it seemed to work fine.
I think on smaller projects that's a fine approach so long as you have your seperation of concerns, don't place business logic in the repository(s) etc. The temptation on a smaller project is to blur the lines but MVC tends to punish you a little when you do that. :)
Larger projects may see you implementing a seperate business class project and maybe even data translation project etc.
MVC Site
app - all static files
--common
----css
------styles-most-pages-use.css
----imgs
------images-most-pages-use.png
----js
------your-custom-lib.js
--files
----release_notes.md
----release_notes.html
--pages
----signin
------signin.css
------logo.png
------signin.js
----dashboard
------dashboard.js
--vendors
----jquery
------jquery.1.11.1.js
-_references.js
Controllers - only thin controllers, just code to call your core library functions
Models - only models that are used to display the view
Views - only client code like html, razor, css, etc
Core library
Basically all code...data access, custom attributes, utilities, etc.
Separating out the core code to just a library is handy for many reasons.
Your logic is not tied to just a web site now. If I need to I can build
a quick front end in WinForms to test some logic or I could use the same
functions in your data access layer to build a admin front end for the database.
I find this structure to be the simplest and most flexible for me.
Update
I'v updated the static content file structure to be more flexible and modern.
I came up with this structure when working with AngularJS. I eventually moved on to
RactiveJS. After moving to RactiveJS the same structure worked really well.
Update 8-21-15 I'v been working on larger projects lately and have been separating the Core library out to its own Visual Studio Project. This makes it flexible when using SVN Externals. I can use the same library across different projects and only need to do a SVN Update to get the changes. Also broke out the MVC Site in its own Project also.
I got similar structure of yours with some exceptions:
- Support is named Infrastructure (namespace for UI assembly usage only)
- IoC is in different project (project for globally used Infrastructure functionality). UI has StructureMaps Registry only with assembly names (IoC is initialized by convention). Approach kind a stolen from CodeCampServer source. Logging, configuration sections goes here too.
- Views/[ControllerName] has Partial subfolder which might be even more divided
(this involves juggling with ViewEngine so it could find views/partial views).- Views/[ControllerName] has LocalResources folder (with Partial subfolder)
- Haven't added any subfolder under Controllers (...yet). I like to keep them clean and quite stupid.
And some more exceptions, related with Model:
- All business logic lives in Domain assembly, Domain.Model namespace with some help of Infrastructure layer for technical aspects.
- View models (i'm calling them ViewData) lives in UI assembly under ViewData folder, structured in folders similar as Views are. Picked approach from Kigg (except that i structure them per View like SearchViewData, sometimes even per partial view).
It works good enough so far
Note that structuring ViewData (i even structure my javascript the same way, View==JS file which contains everything under object named as [ViewName]) per view might not be acceptable for more complicated web sites.
Oh... and => folder==namespace for me. I guess that's a good practice.