ASP.NET MVC – Defining an application architecture


ASP.NET MVC is creating some buzz at the moment and has been long awaited. Being a Microsoft product, MVC will be launched into the mainstream development arena and like webforms, could and hopefully will be a popular web development platform that will be around for years to come . Microsoft and some of the key players in this technology and has already got a good community going. The official ASP.NET MVC site contains some very light and quick code tutorials to illustrate the features of MVC.

Although this is all good, I do have some concerns. It starts with what developers learn, the tutorials on the official mvc site are aimed at developers at different levels and are for illustration only. They are not samples of production quality code. What is missing at the moment are the better practice and guidelines for developing line of business application which I am sure 99% of applications developed with ASP.NET MVC are going to be for.

Separating concerns

On the official ASP.NET MVC site, you will find code examples that are directly fetching data using linq for entities with linq queries directly in the controllers. Its not the responsibility of the controller to fetch data in this manor, their is at least a layer or two missing between controller and data access. My concern is that we will end up with same situation that is present in webforms where applications could be developed with most of the application logic ending up in the controllers (like code behind in webforms).  ASP.NET MVC already is enforcing the separation of concerns for the view but not the controller and model. This is where the design focus is needed.

Layers and tiers

Layering software is probably one of the most basic concepts in the software development that I think is under estimated. I have seen on various projects in the past that its easy to get wrong with either too few or to many layers. I find that logical layers can be defined by separating out the concerns at a high level.

A layer is a logical grouping of code that have a common concern. A tier is typically a physical boundary like a server or client PC. A tier will contain at least one or more layers. Layers that are designed to run in the same tier typically communicate in a finely grained manor (chatty interface) where commutating across tiers should be coarse grain (chunky interface). 

You must either be new to software development have lived in a cave or something if you have not heard of n-tier architecture.  I mention tiers here because i one of the principles that is usually forgotten about in that, when communicating across tiers, do so in a coarse grain mannor.

High above the ground

The architecture that I am defining is nothing new, its a very common scenario using some Domain Driven Design concepts. An alternative variant of this architecture is an SOA implementation. The SOA variant would be the right choice an enterprise level application. The simpler variant of this architecture can be migrated to the SOA variant.

Conceptual logical layers (simple variant)

conceptual logically layers

UI tier – This is the end users computer which will access your application via an internet browser. So the user interface layer will contain (x)html and CSS. Plus this layer could contain JavaScript, silverlight, Flex etc.

Presentation tier – In this tier, you have two layers, the controller and presentation processes. The controller layer will be invoked by the ASP.NET MVC framework in response to an http request. Your controller should do nothing more than delegate any processing to logic in the Presentation Processes layer. The Presentation Processes layer will typically request information from the service layer and process the service response by mapping the information to an object that both Presentation Processes and the controller layer know about. One of the benefits that this gives, is that you could develop your application that is decoupled from the service layer.

Business tier – This tier is very flexible in its implementation. In its most simplest form, it could be run in process on web server that will actually remove the physically boundary between the business and presentation tiers. For enterprise level implementations, this tier could be made up my many separate applications that could be distributed across many application servers. Regardless of the physically boundary, the Server layer should be thin as logic goes. The service layer provides an API to consumers. Beneath the service layer you have the domain layer that contains the business logic and represents the business model. The repository layer is bridge between your application logic and data persistence.

Persistence tier – Does what it says on the tin, this would typically be your database server(s). 

SOA variant


Here is the conceptual logically layers using an SOA approach.


The key difference here is that the service layer is broken up into multiple services that provide a distinct function. SOA is a massive subject that i would not do it any justice trying to sell it, but using this approach gives you many benefits that the development investment is worth it.  If you are have your business tier running out of process or on different services then WCF is the right technology for the job.

Although I have used ASP.NET MVC in the title of this post, this architecture is relevant for most technology implementations. Everything below the controller layer is plain .net code that you could put any .net view technology at the top of this architecture.

Architectural Rules

Rules are needed for any architecture, these are the common rules that I like to stick to.

  • A layer can only see what is beneath it, never above it.
  • A layer must only see the layer directly below it and not the layers further down the layer stack.
  • Use message objects to communicate between layers that are across tiers (although, using message objects between any layer is also good).
  • Limit your cross cutting concerns. (logging and security are typical candidates as a cross cutting concern. Loads of utilities classes/assemblies are not).
  • Strive for low coupling – By enforcing a layer policy where you can only see the direct below helps here. Using interfaces that your concrete classes implement gives you a recipe of low coupling as with so many other benefits.
  • No leaky abstractions.

Next steps

At this point while writing this post, i started to create an ASP.NET MVC application using this architecture. This post was starting to get to big so i have split it up. Here is the next post to continue on this topic.