ASP.NET MVC project structure

 
62   92.8
 
 Feb 07, 2010
My team is migrating over from ASP.NET WebForms to ASP.NET MVC.  Our Visual Studio solution would exist of the following projects:

  • ASP.NET Web App
  • Service Layer
  • Business Layer
  • Data Layer
  • Utilities
It is important to note that our App exposes a public API (represented by the Service Layer).

--

Now, with ASP.NET MVC it seems that everything goes, by default, into a single solution, with Model, View, and Controller subfolders.
However, we are considering separating the original layers like we did before.

Like so:

  • ASP.NET MVC App (with Controller and Views)
  • Service Layer
  • Business Layer
  • Data Layer
  • Utilities
Essentially we are taking the Model out of the MVC App and separating it into Service, Business, and Data Layer.
As mentioned we are relatively new to ASP.NET MVC, so we would like to hear if anyone used a similar approach, or have better suggestions?






 
50   50
 
 23 days ago
I found the M in the MVC slightly confusing at first. The layers I have chosen are similar to yours, as I wanted the Service Layer on top of the Data and Business Layer.

My initial ideas (prompted by some examples from the books on MVC) made me place the model classes (domain/business) into the Models sub-folder of the ASP.NET MVC project.
Of course, it is possible (as I have seen it was encouraged for the sake of simplicity) to ignore the Models folder and make a dependency on the layers on the lower levels, e.g., Service.

At the moment my Models folder is used for keeping objects that are closely related to the presentation layer, such as forms, UI flow-specific objects, and data transfer objects crafted for browser display purposes, etc.).
I did it because in my past projects when I was trying to decouple the service layer from the presentation layer, I found that services 'knew too much' about the flow, hence the need for something in between. I know that some people might frown upon yet another layer between the UI and the business logic layer (or services layer, in the matter of fact), but that is what I have found useful so far.
So in my case the Models folder serves a purpose of separating the UI-specific stuff (such as forms, their temporary data, states, flow logic, etc.) from the service layer. I would not keep Data Layer or reusable services in Models, in my case that would go outside ASP.NET MVC project to something like Integration layer that serves a purpose of mediating between clients (UI is just one of them) and the Service and Business Layers.
The increased number of layers makes the system more flexible and easier to evolve and maintain in the long term.