Let there be MVC - and it was good

Introduction

This is the beginning of my new MVC article collection. I decided to write on MVC and create decent lessons for it.

Even though there are plenty of lessons out there, I want to approach this in a manner in which my fellow developers can understand. I know their background (ASP.NET WebForms), so therefore know how to get them to understand it.

So let us begin...

MVC, which is an acronym for Model - View - Controller is no new concept. In fact this design paradigm was created by Xerox in the 80's, and it is becoming THE recommended model for designing frameworks - especially on the web. Most windows forms developers will already understand this model from using BAL's and DAL's.

What makes MVC great is the way it enforces code separation between the different layers of abstraction - being the Business Models, Processing and finally the output.

By doing this in ASP.NET MVC, we can obtain the following advantages:

• Provides clean separation of concerns (SoC).
• Enables Test Driven Development (TDD), which I will cover in an upcoming article.
• Easy integration with JavaScript frameworks such as jQuery, making Ajax beautiful, and giving the ability to create stunning GUI's.
• Following the design of stateless nature of the web.
• RESTful URLs which improves SEO.
• Enables the full control over the rendered HTML.
• No dodgy ViewState and postback events - cutting out on page size and complexity.

Like most frameworks, MVC isn't perfect and does have some drawbacks. Some that I can mention are:

• The complexity is high to develop the applications using this pattern.
• Not really suitable for small applications which has adverse effect in the application’s performance and design.
• The isolated development process by UI authors, business logic authors and controller authors may lead to delay in their respective modules development. (Although usually the business logic and controller authors are the same guys).

How MVC works

Each part of MVC has physical elements within a web solution/ projects. Below I am going to outline each part and explain what it does:

The Model

The model represents the business rules and data, and is where most of the processing takes place when using MVC. Databases fall under the model, as do component objects like EJBs and ColdFusion Components. The data returned by the model is display-neutral, meaning that the model applies no formatting. This way, a single model can provide data for any number of display interfaces. This reduces code duplication, because model code is only written once and is then reused by all of the views.

The View

The view is the interface the user sees and interacts with. For Web applications, this has historically been an HTML interface. HTML is still the dominant interface for Web apps, but new view options are rapidly appearing. These include Macromedia Flash/ MS Silverlight (although it is no longer going to be updated due to the awesomeness of HTML5)  and alternate markup languages like XHTML, XML/XSL, WML, and Web services.  

The Controller 

The controller interprets requests from the user and calls portions of the model and view as necessary to fulfill the request. So when the user clicks a Web link or submits an HTML form, the controller itself doesn’t output anything or perform any real processing. It takes the request and determines which model components to invoke and which formatting to apply to the resulting data.

Below is an image I grabbed from the web demonstrating the Model - View - Controller relationship.