I'm coming from a web forms n-tier background into ASP.NET MVC projects, and I'm wondering what the best practices are for separation of the components of MVC into different libraries (or not to) in the way one might with an n-tier model. Most of the sample apps I have seen only had one project file and objects were separated only by folder.


1 Answer 1


A typical multi-tier application looks like this:

enter image description here

In an MVC application, the data tier and logic tier reside in the Model, while the presentation tier resides in the View. In between the Model and the View, the Controller provides a switchyard, routing web requests and responses to the appropriate methods, views and model logic.

Within the Model, you can have as many or as few libraries as you like. For the View and the Controllers, I would say a good rule of thumb is one DLL per web application or service. Services might include a REST web API for external applications.

The Model typically contains at least three things: the database, the Business Logic, and a Service Layer. The Service Layer is implemented as a series of classes and methods that represent the domain objects called Repositories. Within these Repositories, it is not uncommon to use an ORM to provide object-level abstraction for the database.

Rules of thumb: Fat Model, thin controllers. The View historically has as little domain logic as possible, although nowadays the web interfaces are getting smarter from a client-side standpoint, with jQuery, HTML5 and sophisticated client-side frameworks like Kendo.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.