Much has been written about ASP.NET and ASP.NET MVC, but my Talking Points would be incomplete without it. In fact the first Talking Point was on a subject central to the ASP.NET MVC architecture: Routing. MVC pattern is new to our Microsoft Web Dev Platform, but it is a useful pattern that has been around for about 30 years now (circa 1979 - MVC). I like the approach because it is a very clean pattern that makes your application easier to understand and easier to maintain.

ASP.NET MVC Tenets

•The main tenets of ASP.NET MVC are Alternative, Testable, Extensible and Routable.

• Alternative
  • ASP.NET MVC builds on top of ASP.NET, it doesn’t replace it. It is simply meant to serve as an alternative approach to developing web applications using ASP.NET.
• Testable
  • While WebForms can be tested, it isn’t the most trivial task. ASP.NET MVC was built with testing in minding, so practicing Test Driven Development (TDD), or just simply writing unit tests, is a simple task with MVC.
• Extensible
  • MVC follows the convention over configuration principle. At the same time, it isn’t meant to constrain developers by its conventions. MVC is built on an extensible framework that virtually every component can be easily replaced with your own logic.
• Routable
  • ASP.NET MVC uses ASP.NET Routing to associate URL patterns with controller actions. This means that your MVC applications will naturally be search-engine optimized, since every controller action that corresponds to an HTTP GET can be easily discovered.

WebForms

In WebForms today you start out with an ASPX page, within the page you can have any number of user controls, custom controls, and server controls. In addition, a page can have a master page, which can in turn have any number of controls itself. When you introduce model data, due to the level of abstraction needed by WebForms, any of the components used can have access to data. The page, the master page, and any of their individual controls contain logic that both retrieves model data and contains its view representation. This is a model that has made WebForms very successful and useful for web developers.

Page Controller (ASP.NET)

WebForms uses a pattern called Page Controller. When a request comes into ASP.NET, the request is served by a specific ASPX page. Hence, the page itself serves as the controller, or face of the object that handles the request.

Front Controller (MVC)

While WebForms  implemented the page controller pattern, where the individual page serves as the actual handler of the request, with  MVC, it implements what is called the front controller pattern.  When the request comes into ASP.NET, the request is routed to a controller object:

• The controller accesses the model data, if model data is needed
• The controller takes the model data and passes in to the view, which then serves the request.

Model-View-Controller (MVC)

MVC is an architectural pattern that separates model access from presentation logic. It adds specific responsibility to individual portions of the application.

• The model represents your business objects, that both houses your data, and contains business logic.
• The view acts as a representation of the model data it is given by the controller.
• The controller is responsible for interacting with the model, and then passing that data down to the view.

ASP.NET MVC

A  typical ASP.NET MVC application contrasts significantly to the way the structure of a WebForms application looks.

In an ASP.NET MVC application we still have our ASPX page, which in turn can leverage user controls, custom controls, and server controls. Nothing different here.

The page can be associated with a master page, which can in turn have its own set of user controls, custom controls, and server controls. So far this is still the same as WebForms. We re-introduce the model data, which is where the contrast between WebForms and MVC gets clearer:

• With WebForms, any of the controls, or page, or master page was directly interacting with the model.
• We introduce the controller into the picture, which will now act as the orchestrator between the model and the views.
  • Here, instead of the pages and controls directly accessing the model, the controller is strictly doing that. Once it gets the model data it is responsible for passing the data to the page, or view.

ASP.NET vs ASP.NET MVC (What’s in it, what isn’t)

Just to reiterate the point that MVC is built on top of ASP.NET, here is a list of similarity between the two:

• Web designer
• Master pages
• User controls
• Membership/Roles/Profile providers
• Globalization
• Caching
• The HTTP intrinsic

But, while MVC is built on top of ASP.NET, it doesn’t have:

• Post-backs
• View state or control state
• Server-side form
• Page/control lifecycle*

* The page/control lifecycle is still present if you’re using WebForms as your view engine, but even then, you most likely won’t be using it.

Controller Conventions

There are a lot of conventions centered around the controller that are important to be aware of.

• When you create a controller, the class name must be prefixed with “Controller”, hence a controller for customers could be named “CustomerController”. Everywhere you refer to controllers you do so with the “Controller” portion, because the framework knows to append it on for you. This behavior is similar to attributes.
• A controller must ultimately implement the IController interface. ASP.NET MVC provides the Controller class which implements IController and provides a lot of beneficial behavior. Most times you’ll create your controllers by inheriting from Controller, but if you need complete control you could implement IController.
• When you create an action method within your controller, it has to be a public method that returns an ActionResult (or a derivative).
• The action method can’t be generic, can’t have any out/ref parameters, and can’t be salted with a NonActionAttribute.

Summary

For developers used to the direct mapping approach of ASP.NET it may be a challenge to let go of that model and adopt the MVC. That is why one of the tenets of ASP.MVC is alternative because it is just that: Another approach to building ASP.NET applications. For those of you with a preference for preserving a clear separation of concerns for the different “layers” of your web application ASP.NET MVC is for you.

References

You can find just about everything you would ever need to know about ASP.NET MVC at www.asp.net/mvc. And also you can check the massive collection of videos on the subject here.

Joel Reyes