ASP.net MVC project structure

Question

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 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 2

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.

Answer 3

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 4

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.