MVC (Model View Controller) is the new word for ASP.NET developers. Though it's almost 1+ years old (CTP was released on 12th DEC 2007), it started suddenly buzzing the market. Everybody is talking about ASP.NET MVC now. So I thought of putting an article regarding this, hope this will help people who are trying to learn the new framework from Microsoft. Oops... did I say that, is it a framework?? We will see.
You can find a lot of articles regarding the new framework on the internet. What this article is trying to convey is when to decide to use this framework over existing ASP.NET models (the web forms basically)... a comparison that will help in decision making.
What is MVC??
As I said earlier, this is a new framework provided by Microsoft to design and develop a new generation of web applications on .NET platform. Go to Wiki, Google and you will find that this is an architectural design pattern. A new generation since the model in which classic ASP.NET page work, it’s different from that.
This is a framework methodology that divides an application's implementation into three component roles: models, views, and controllers.
- Models: These are the components of the application that are responsible for maintaining state. Say a model maps to a database table with the entries in the table representing the state of the table.
- Views: These are the components responsible for displaying the application's user interface. A View extracts necessary information from a model and renders a user interface to display that.
- Controllers: These are the components responsible for handling end user interaction, updating the model to reflect a change in the state of the application, and yes finally choosing a view to render to display UI. This is the heart of the framework.
Why MVC, The New Framework?
Now here is the big question that why we need a new framework and architecture altogether for developing web applications. Are we not happy with the more than half a decade proven technology of Microsoft for doing the same work, that’s web forms (classic .aspx pages). Let us see.
Remember the initial days of ASP.NET 2.0 learning, people have the tendency of mixing up the presentation layer with data access and business logic layer. Especially I remember the sqldataSource control embedded to an ASP.NET server control. See this:
Web applications developed this way are quite difficult to maintain. And they are definitely challenging to test appropriately. Oh yes, have you ever tried to test the full ASP.NET application? It's impossible unless you tweak the runtime environment. You can test the classes in your separated BLL or DAL but not the UI. This is just an example and we have a lot more of this kind. So your boss asks you to read about best practices, design patterns so that you can separate the layers properly, hence it can be reusable, testable and maintainable. Read Google Separation of Concerns to understand.
MVC does not support post back and view state (the culprit behind page performance), it does not consider the URL to map to a particular physical file on server as in case of web forms. It's just a logical one in case of MVC. So in MVC, you can have custom format and the engine will handle it to render it correctly. How does it do that------------for this please wait to check my next article on Httphandlers and how they handle things in MVC-----------for the time being remember that it’s a factory of httphandlers which is centralized and handles the requests. This HTTP handler analyzes the syntax of the URL and maps it to a special server component known as the controller.
Models and controllers are just simple *.cs files containing interfaces, classes, methods……View is the most interesting here, which is pluggable. That means you can have .aspx, .ascx pages anyway for rendering your controls and text, but also you can have your own view engine created to render contain and you can have your file name extensions as*.abcde and this will be taken care of by the httphandler. For example, you can see one screenshot on how we use an XSLT based view engine to render our content. You can have some other view engines here. MVCContrib library contains 4 alternate view engines, Brail, NHaml, NVelocity and XSLT.
Don’t try to understand this. This is what we use in our organization. I will put up an article altogether about how to write your own view engine. That’s kind of hard but before that, it will have a series of articles.
Ok so we were discussing postbacks, view state and rendering engine. In MVC, the default engine is Web Forms view engine, and that’s why you have .aspx and .ascx files in your MVC framework. So you can have server controls in your pages, have event handlers and render contents, then a question, why MVC?? Again. Ok you can have all those but you don’t have view state in MVC for having the state of the server controls. Of course you can overcome that using sessions, cache objects, etc. If MVC does not have server controls, then what? We have only HTML controls. So how do we do RAD (Rapid application Development), as we do in ASP.NET. Ok we have HTML helpers in this case and I am eagerly looking at any third party or Microsoft to come up with some controls for rapid development in MVCframework. Just have a look when you develop applications in MVC in VS 2008. I am here using the example of nerddinner which is written by scott gu and others. He also has a free book which is a walkthrough of the application with code examples. Though the code provided in the book does require some correction so that the app runs correctly in production, it's almost a complete app you can build from scratch on your own. The errors are minor.
This is how one of the aspx pages looks like and it does not have any page behind code (Separation of Layers).
So what do you have generally on the pages. It's nothing but HTML controls and links with parameters. So unlikeASP.NET pages, these pages are search engine friendly and rank well by search engines. Note: MVC does not have page life cycle concept.
Before I go to other topics or conclude the article, let's talk about the TDD (Test driven development) aspect of MVC. As we see, it's difficult to have a test driven development approach for the full ASP.NET application, it's easy for MVC apps. Since all the three roles (M—V—C) have a clear separation of controls, it's easy to test the full application and that too injecting required test data from the application itself. Please Google regarding Dependency Injectionframework and mocking frameworks.
What to Choose
Few points which can help you:
|Scenarios||What to choose??||Remarks|
|Your developers love drag and drop control from the tool box and raw HTML is a nightmare for them||Web forms||Classic ASP.NET controls are abstractions of HTML, with “runat” server attribute.|
|Your Application demands fancy visual controls to display data. Even if it requires something like
||Web froms||MVC only has HTML helpers. Some of those are:
And you don’t have much choice. We never want a
|You want to achieve Separation of Controls build into the system/framework and you don’t need to bother||MVC||SOC is in the architecture of this framework. With web forms, you can achieve SOC but you need to do that on your own with some best practices while writing your code.|
|You want to test each and every component of your application right from the beginning, without connecting to databases||MVC||MVC was designed by keeping testability in mind.|
|Let me know if I missed any major one.||Web forms is mature and MVC is young which lacks component model. But needless to say it leads you towards a good code design.|
I know this is not all and maybe I have not put the things well. I just tried to give an overview of both the models and few features of those. Hope this helped to find the line between those 2 models. So to conclude, what to choose as that was our goal, you need to decide. If it's a heavily data driven site, then probably MVC may not fit in. But if its data driven where you don’t have fancy requirements for data display or something of a similar kind and for other types of development, MVC is a good choice. But before choosing any one of them, the architect needs to understand the underlying methodologies of both. This is just a simple work to identify those.