I have created the following project structure for my new asp.net mvc project any I was after some feedback as how other people are structuring their projects and if I would improve mine...
Here is what I have so far:
+Assets
-+Images
-+Scripts
-+Stylesheets
-+... 'More things like the above here
+Controllers
-+Support
--+Actions 'Any custom action classes
--+Controllers 'Base controller classes
+Models
-+Domain 'Contains any class that specialise view specific domain logic
--+UrlProcessing 'Encoding/decoding business entities as URL parts
--+... 'More things like the above here
-+Views 'Contains view models
--+Support
---+Views 'Base classes for any view models
+Support
-+Application 'Global application interface classes (i.e. class that wraps the function of the global asax)
-+Configuration 'Typed config classes
-+Helpers 'Where you put additional html helper classes, etc
-+Services
--+Bootstrap 'Tasks that run on mvc start-up that are specific to the MVC project
--+Inversion 'Specific IoC registration registrations for this project
--+... 'More things like the above here
+Views
-+Home
-+Shared
-+... 'More things like the above here
Cheers Anthony
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.