Background
MVC is the new buzz in development word, everyone is talking and developing with
mvc. Knowing how to use Asp.Net MVC is easy, google can give you hundreds of good
resources that shows how to configure and write codes. But from my point of view
its always better to start from asking why before asking how. Moreover MVC is not
alone it wraps around lots of other concepts like db first model first, code first,
razor, TDD and so on and on.
Each concept itself is a giant and if you google, will find lots of good resources
on them. Starting from this post I am planning a series of articles explaining each
of the above concepts or more and slowly move forward to implementation applying
these concepts explaining benefits/drawbacks of using those. So plan is to take small
steps to reach to the ends. In this first post will discuss benefits, applicability
of MVC and life cycle of Asp.Net MVC.
Why MVC
"Splits user interface interaction into three distinct roles. - Martin Fowler" was
the core motivation of MVC. Initially MVC was born as the outcome of the battle of
application logic vs user interface. Now abovious question is whats is this all
about? Idea is to keep a good separation between the presentation of a program (which
is UI) and the rest of the functionality. A separation lets you address on each
aspect of the layer separately—and one complicated thing at a time. It also lets
specialized people to work on the separate pieces codes. In effort to make both
of distinguished an approach/pattern was needed and this approach is the most highlighted
part of Model View Controller (MVC). Separation of view from rest of the application
logic open a door to change the view logic in future. May be afterwards client asking
for more extractive UI or more UX support or worse a complete makeover. If view
logic is tightly coupled with business logic's it will be difficult to made the change.
The MVC pattern was first implemented as part of the Smalltalk class library. It
was originally used as an architectural pattern for creating graphical user interfaces
(GUIs). Later when adopted in the web application the meaning and applicability changed
radically. The motivation behind MVC is re-usability and separation of concern. All
other benefits is stand on this two building blocks.
MVC Candidates
This has been a huge confusion whether to use MVC or not. But I believe there is not straight answer, it all depends on the application type, resource and time you have to implement and most importantly how much control we need on the application. So bottom line is we must consider carefully whether to implement a web application by using either the Asp.Net MVC framework or the Asp.Net web forms model. MVC has a lot of things to offer, but there are a few areas that we should consider before made the selection.
MVC suitable for web applications that are supported by large teams of engineers and UX designers who need a high degree of control over the application behavior.
If working small teams of engineers and UX designers who want to take advantage of the large number of components available for rapid application development then MVC is may not be a good choice.
You should not use Asp.Net MVC if you rely on 3rd party vendor controls for of the UI.
MVC leverage the power of object-oriented programming by interfaces, classes and other OOP principles. If some one is not well-versed with these object-oriented concepts, then the framework might not be comfortable for that person.
But if you want to use automated testing, plug-gable architecture, full control over rendered HTML and rich UI support then MVC (in our case Asp.Net MVC) is the best choice.
Asp.NET MVC
The ASP.NET MVC Framework is Microsoft's effort to create an ASP.NET programming
environment warped around the MVC pattern. Like the official site says "ASP.NET
MVC is a framework for building scalable, standards-based web applications using
well-established design patterns and the power of ASP.NET and the .NET Framework.",
Asp.net MVC is sitting on top of .NET framework and utilizes the core functionality
of asp.net. And it defiantly does not mean web forms are now extinct or too old
to use. In my opinion Asp.net MVC is a better way to doing stuffs that we are used
to do with web forms.
Now the question is how difficult is to adopt this new framework for developers
who are used to with RAD(Rapid Application Development) style? and the answer is
its very easy. How? though we are using MVC we are still using visual studio and
we are still utilizing asp.net framework, isn't that cool? Yes server controls are
not available , but think about how clean the markup would be if there is no server
control and as the model/view are all separate testing is lot easier. In the context
of our very own ASP.NET web applications, the model, view, and controller participants
can be explained as:
- View: This is the HTML markup in ASPX pages. This is rendered in the presentation
tier (the browser).
- Controller: This refers to a simple class controller that decide which model needs
to be shown respect to which view.
- Model: This a layer who deals with data, which may be processed by the business
layer.
Page controller pattern, which is the default architecture in the ASP.NET web forms
has some limitations.Each page in application has a separate page controller so
there could potentially be a lot of code in the code-behind files and lots of maintenance
effort. Second issue is testing the application, especially the GUI and the code-behind
classes is very difficult, and we cant use test automation tools. Unlike web form
which use Page controller pattern, MVC is based on a front controller design, where
a centralized controller decides which view to render. And as model, view and controller
are all separate so automated testing has never been easier as today with Asp.Net
MVC.
Benefits
Before we come to conclusion whether to use MVC or not lets look couple of benefits
of using MVC:
- Distribute development effort to some extent, so that implementation changes in
one part of the Web application do not require changes to another. The engineers
responsible for business logic and engineers responsible for flow of control, and
Web-page designers can work independently.
- Easily prototyping is possible. You might do as follows, for example: Create a prototype
Web application that accesses several workstation-based programs. Change the application
in response to user feedback. Implement the production-level programs on the same
or other platforms.
- You can more easily migrate legacy programs, because the view is separate from the
model and the control and can be tailored to platform and user category.
- You can maintain an environment that comprises different technologies across different
locations.
- The MVC design has an organizational structure that better supports scalability
(building bigger applications) and ease of modification and maintenance (due to
the cleaner separation of tasks)
- It does not use view state or server-based forms. This makes the MVC framework ideal
for developers who want full control over the behavior of an application.
- It provides better support for test-driven development (TDD).
- It uses a Front Controller pattern that processes Web application requests through
a single controller. Thus can design custom routing infrastructure
And if we consider web forms as an alternate, lets see what web forms has to offer,
- It supports an event model that preserves state over HTTP, which benefits line-of-business
Web application development. The Web Forms-based application provides dozens of
events that are supported in hundreds of server controls.
- It uses a Page Controller pattern that adds functionality to individual pages. For
more information, see Page Controller.
- It uses view state on server-based forms, which can make managing state information
easier.
- It works well for small teams of Web developers and designers who want to take advantage
of the large number of components available for rapid application development.
- In general, it is less complex for application development, because the components
are tightly integrated and if we consider LOC then require less code than the MVC.
Asp.net MVC Lifecycle
To Understand the MVC request execution Process, we have to start from the very beginning which is IIS. Lets look at it from an IIS perspective now. As Asp.NET MVC
is sitting on top of asp.net framework, so from the user request intercept by HTTP.sys
to worker process processes the request stays the same as as asp.net web application.
Though ASP.NET is executed in different ways in different versions of IIS, but thats
discussion is out of context for now. We will concentrate the part where the HTTP
request enters the the MVC Framework.
Asp.Net request processing can be described in 4 simple steps:
- Step 1 – Routing : This first step once an ASP.NET application first starts.The
UrlRoutingModule intercepts every request. To let MVC routing handler to process
requests, configure the routing table during application start-up is required. While
configuring MVC with default template, a default routing configuration is provided
in global.asax file.
- Step 2 – MvcHandler : The MvcHandler creates a controller, passes the controller
a ControllerContext, and executes the controller.
- Step 3 – Controller : The MVC controller factory locates and creates the controller
in CreateController. The controller determines which controller method to execute,
builds a list of parameters, and executes the method. The ControllerContext is passed
to the Execute() method on the controller class.
- Step 4 – Action : Controller methods end with a call to either the RenderView()
or RedirectToAction() method. The RenderView() method is responsible for rendering
a view (a page) to the browser. The Controller.RenderView() method delegates its
work to a particular ViewEngine.
In Short the steps are,
Request -->Routing --> MvcHandler -->Controller --> Action
The process described above is default behavior, but asp.net MVC allow fine tune
the process according to need, even you can improve performance by using specialized
controller like asynchronous controller. As of now we covered with basics of MVC asp.net , hope I didn't missed out any basic concepts. In next post we will take a deep
dive into Asp.Net MVC describing how to utilize mvc built-in features comparing
to web forms.
One important tip is when an ASP.NET MVC Web application runs in IIS 7.0, no file
name extension is needed but in IIS 6.0 you should map the .mvc file name extension
to the ASP.NET ISAPI DLL.
Design Patterns in MVC
Even though MVC is design pattern itself, the entire MVC framework contains some design patterns itself. Below is a list of design parrens used in MVC (or Asp.Net MVC) regardless the
platforms. Detaild description of these patterns in MVC are out of the scope of this post, I am sure you can google and could know much more about them.
|
Front Controller
|
Consolidates all request handling by channeling requests through a central controller.
|
|
Strategy
|
The View-Controller relationship, The way conroller hookup view at runtime.
|
|
Factory Method
|
Specify the default controller class for a view
|
|
Decorator
|
In the context of MVC, decorator could fit into your views.
|
|
Observer
|
One Model, Multiples views ( observers/subscribers ), and the publisher manages
the communication
|
|
Mediator
|
Several different Models, Several views, and the mediator manages the communications
between them.
|
References and Good Reads
Series Plan
- Why(s) & How(s) of Asp.Net MVC Part 1 - MVC Basics
- Why(s) & How(s) of Asp.Net MVC Part 2 - Playing with Asp.Net MVC
- Why(s) & How(s) of Asp.Net MVC Part 3 - DB First
- Why(s) & How(s) of Asp.Net MVC Part 4 - Model First
- Why(s) & How(s) of Asp.Net MVC Part 5 - Code First
History
Version 1.0
