MVC and n-layer architecture

When I write a program, no matter which tool I use, one problem I face is how to design the application. No matter if you use Java, PHP, or Visual Basic; if you design the application badly, you will have problems later when you try to fix bugs or enhance the product to the next version.

The MVC design pattern
MVC stands for Model, View, Controller. This is a very common design pattern used in programming today. When someone uses a MVC application, they make a request to a controller. The controller then talks to the model, which consists of business logic, to perform the action requested. The controller then processes the information from the model and sends it to the appropriate view.

By using the MVC design pattern, you will separate your business logic from your presentation HTML. This makes your application more easily maintainable because a bug can be fixed in the business logic without all that HTML display code getting in the way. Also, when multiple developers are working on a project, the developers who write HTML and CSS can work independently of the core programmers.

N-Layer Architecture
N-Layer, or multi-layer, applications are designed using layers that handle a single responsibility. Many applications use three layers; Presentation, Business Logic, and Data-Access. This is similar to the n-tier architecture, but the primary difference is tiers represent physical hardware, while layers represent software.

In the three-layer approach; the Presentation layer would consist of the user interface, the Business Logic would consist of objects that process Business Rules, and the Data-Access layer would talk directly to the data source. This design usually works well.

Putting them together
One of the things I found a little confusing about MVC at first was what exactly is the model? After much research and testing, I finally found something that makes sense to me.

MVC Multi-Layer Diagram

MVC Multi-Layer Diagram

 The diagram above is the general layout that I use when developing a MVC application. Here is a brief description of the various components of the diagram:

  • Model – In this diagram, the model would consist of the Services, Repositories, and DatabaseConnection layers along with Domain Objects.
  • View – The view is the presentation or design elements of the application; such as HTML or CSS.
  • Controller – The controller is the layer that drives the application. It processes requests from the user and sends them to the model and then returns the processed information to the view.
  • Services – This layer handles requests from the controller. This is the layer that contains the business rules on how the application should function.
  • Repositories – This layer performs CRUD (Create, Read, Update, and Delete) operations on the database.
  • DatabaseConnection – This layer is further abstraction between the data source and the repository. It is not required, but I typically use it when I need to work with multiple databases. The DatabaseConnection layer was built to generalize between three different database drivers and use common methods to work with each.
  • Data-Access layer– This layer would consist of the Repositories, DatabaseConnection, SQL Data Source and Other Data Sources.
  • Other Data Sources – This could include a XML file, other database, or even a web service.
  • Domain Objects – This is not necessarily a layer, just a collection of objects used to make it easier to work with the data from the data source. Notice that all of the other layers need to be able to work with these objects. An example of a Domain object might be an Employee class that stores information about an employee and is populated from a data source in the Repository. The Employee object can then be passed from each layer back to the view where it is displayed to the user.

This is just a brief overview of MVC with the n-layer approach.

You may also like...

4 Responses

  1. Shaun says:

    I enjoyed reading this posting. It is well written. I have a couple of comments/opinions.

    I think your diagram should have three layers in which everything else resides: Persistence, Model, and Presentation…

    The three tier architecture was suggested by David Anderson in the following post and I agree with most of his approach:

    There should be a Persistence layer consisting of the Repositories, (Database Connection and Database), and (Data Connection and Other Data Sources).

    The Model layer should be visible in the diagram. The Model layer should include the Services and the Domain Objects, in addition to the business/problem logic.

    The Controller is a logic unit handling input, so it it should not need direct access to the Domain Objects. Dealing with the Domain Objects should be limited to Model layer entities.

    You may also want to give some thought about peeling out the View (output) and Controller (input) into a Presentation layer, as suggested by both David Anderson and Aviad Ezra, although I don’t agree with everything Aviad Ezra says either, as it does not quite fit the next generation web apps, but comes very close IMHO:

    Merging what you propose in with what is proposed in the other two posts, plus making the browser a client-side Presentation layer, makes for a very workable paradigm for the next generation browser applications (notice I did NOT say “web applications”). I’d post a diagram, but these comments are text only. :)

    Just my 2 cents.

  2. @Shaun
    Thanks for your comments!

    I could not get the first link to open. My computer could not find the domain.

    I am (constantly) searching for ways to improve my application designs. This post has already fallen out-of-date with my current designs which somewhat follow with what you have suggested.

    Currently, I do use a persistence layer which contains my repositories, data connections, other data sources, etc. This layer also contains my domain model.

    I also use a Service layer (model) which contains the service classes.

    The user interface items (controllers / views) reside in my main MVC project along with some helper classes that return HTML to the views.

    While I like the idea of having a domain model in the service layer and kept hidden from the other layers, I’ve ran into problems that forced me to revert back to my current design just to get the work done.

    I really like this design:

    I think the Onion Architecture keeps your code cleaner and will help limit rewriting and retesting code. You should check it out. I think this design would go well with your ideas.

    So far the problems I’ve seen with Onion Architecture are:

    – The outter-most layer (that starts the application) needs to be a Dependency Injection layer and I have not figured out how to make this work with ASP.NET MVC.

    – When data is passed from the repositories (which have their own model) to the service layer (the domain model), mapping must be done to copy the data from how the database is designed into how you want to use it in your model. Changing something in the database becomes a pain because you have to update your database model and the mappings.

    – Creating view models began to get too bulky, but this was probably due to me trying to use the same view model for many different views. It probably would have worked better by creating a separate view model for each view.

    I want to migrate into the Onion Architecture design, but I still need to resolve a few more issues.

  3. This is really most clear to me. Especially Domain Objects is accessible in all layers will make it easy instead of having another duplicate DTO objects in service layer. Thanks!

  4. dario-g says:

    Read this ( blog and everything becomes clear to you. Especially everything about MVC and IoC/DI. :)

Leave a Reply

Your email address will not be published. Required fields are marked *