ASP.net MVC project structure

Question

Hi guys 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

Answer 1

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.

Answer 2

I got similar structure of yours with some exceptions:

1. Support is named Infrastructure (namespace for UI assembly usage only)
2. 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.
3. Views/[ControllerName] has Partial subfolder which might be even more divided
   (this involves juggling with ViewEngine so it could find views/partial views).
4. Views/[ControllerName] has LocalResources folder (with Partial subfolder)
5. Haven't added any subfolder under Controllers (...yet). I like to keep them clean and quite stupid.

And some more exceptions, related with Model:

1. All business logic lives in Domain assembly, Domain.Model namespace with some help of Infrastructure layer for technical aspects.
2. 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.

Answer 3

I think this is a bit overcomplicated but if it makes sense to you go with it. The important thing is to keep balance.

One thing I do like to go with separate projects within the solution as it allows for reuse of Data Access and Business Logic to be reused by other client application types such as WPF or WinForms Clients.