Everyone is talking about the Model View Controller, or MVC, pattern. In this post I’m going to focus on the pattern itself and the concepts around it for anyone who hasn’t come across this pattern before, or who just wants a simply refresher. The pattern itself has been around for many years, way back to the days of smalltalk, however has become popular and came into the limelight over the last number of years with different web frameworks ‘encouraging’ the use of the pattern.
The pattern describes how to separate your business logic (what the application should do) and the UI (how it looks). There are huge advantages to this:
- It promotes code reuse as code isn’t isolated in a button’s click action
- Maintenance of the application is easier as changing one side of the system doesn’t have the additional noise of the other side. When changing your business rules, you don’t have to interact with the code which displays everything on screen.
- UI is difficult to test, if you remove the UI then testing becomes easier. As everything is more separated and has cleaner interfaces, it becomes easier to write your automated test cases.
- Having everything separated means different parts can be interchanged/replaced easier.
What the pattern is really attempting to achieve is a separate of concerns with the different parts of the system just dealing with their own responsibilities.
However, most applications do not follow this pattern and mix up all the layers together. Microsoft samples are quite bad for doing this where they have SQL connections and queries in a button click event. However, the current architecture of WebForms doesn’t fit well with the MVC approach (of course part from the new MVC framework). The reason it doesn’t fit well is because you can have SqlDataSource and DataGrids on the webpage which contain sql statements and database connections resulting in just a single UI layer. This is fine for Rapid Application Development (RAD) and very quick sites, but for enterprise level applications this approach is not maintainable.
By following the MVC pattern, your application will be architected in a very different manner. There are three main components to the system:
- Model – Object representing data or state within the system. This could be an ‘Order’ object which represents a row in the database or maybe an arm on a robot.
- Controller – This handles the application flow. This handles which views should be rendered, which data to display and any validation which is required. This is most definitely not a God Class and its important not to put everything into a single controller.
- View – The single role of a view is to correctly display the data. It takes the model given to it from the controller and outputs it in the correct way.
With an application separated in this way, we can replace different parts of the application without affecting too much of the application. How we actually implement the pattern is dependent on the platform building upon. It is possible to implement this pattern in any system, however the new ASP.net MVC Framework will definitely help in managing the interaction.