An Ideal Folder Structure for .NET MVC [closed]

Question

When I started in .NET Webforms I didn't have much trouble finding a folder structure to follow since VS offered you application folders like "App_Code" and most app examples put "BLL", "DAL" inside there and so on.

But now in MVC, every example I check uses different structure, like no standards this time and I haven't found a good solution on Google or SO.

So, maybe we can share how we organize our MVC projects, may help others to make their own mind. Here is the structure for small to medium projects I use:

App_Data
Areas
    Admin
        Controllers
        Models
        Views
    MyAccount
        Controllers
        Models
        Views
Content
    Images
    Scripts
    Styles
Controllers
    HomeController.cs
Helpers
    ExtensionMethods    // I.e. based on HtmlHelper, use "helper" suffix
        MenuHelper.cs    // to be called as html.Menu()
    Utilities.cs    // Other generic (static) libraries, no suffix used
Models
    ViewModels    // for passing models to Views
        RegisterViewModel.cs    // use "ViewModel" suffix
    Customer.cs    // to extend models like adding Model Validation
Repositories
    CustomerRepository.cs    // use "Repository" suffix
Services
    CustomerService.cs    // use "Service" suffix, to move code away from controllers
Views
    Home
        Index.cshtml
        Register.cshtml
    Shared    // Site Layouts (Master templates), also put partials here
        SiteLayout.cshtml

What about yours?

Answer 1

I have found it simplifies deployment to have the website project contain only content (no compiled code).

Something like:

Web.Site project

   Content       Images       Css    Scripts    Views    web.config 

And move all compiled code into another project:

Web project

   Controllers    Filters    Models    ... 

Then, you can treat everything within the Web.Site project as needing to be deployed, and all required assemblies will be in Web.Site\bin.

Whether you are doing simple xcopy deployment, or using WiX to build an MSI package, this will make life a little easier.

Answer 2

I second the two project approach. Jimmy Bogard has a nice post on the approach as well (make sure to go through all the comments).

I personally find that when I'm working on a part of an application I use related services, controllers, repositories, etc.. and when you put each of these files in a different folder it can get tedious going back and forth and finding them. After some playing around I've been following this format:

AppName.Web.UI

Scripts
Content
View

AppName.UI.Core

Attributes
Filters
Formatters
Helpers
Models
  Company
     Interfaces
       IController.cs
       IRepository.cs
       IService.cs
     ViewModels
       ViewModel1.cs
       ViewModel2.cs
     Controller.cs
     Repository.cs
     Service.cs
  User
    ....
Plugins (mailchimp, Twitter OAuth, etc..)
Global.asax (define all the code here rather than in the UI project)

Test Project

  ...

I think it depends how large your project is as to whether you further break down and use Interface and ViewModel sub folders. Its not perfect, but I've found it meshes better with the way I think.

The case can also be made to put your services and repositories into a third project (AppName.Core), leaving the AppName.Web.Core project encapsulating only Web relates parts (Attributes, Controllers. ViewModels, etc..). Again that really relates to the complexity of the project.

Answer 3

So long as it's clear where things are, it doesn't matter much. I think it's just a matter of being consistent within your organization/group.