(1) No Resting upon ViewState and Postback
The
ASP.NET MVC framework does not use the ASP.NET Postback model for
interactions with the server. Instead, all end-user interactions are
routed to a controller class. This maintains separation between UI logic
and business logic and facilitates testability. As a result, the
ASP.NET view state and ASP.NET page life-cycle events are not integrated
with MVC-based views.
Also, the MVC framework doesn't consider
any URL as the endpoint to a physical server file to parse and compile
to a class. In ASP.NET Web Forms, you have a 1:1 correspondence between a
URL and a resource. The only exception to this rule is when you use
completely custom HTTP handlers bound to a particular path.
In the
MVC framework, a URL is seen as the means to address a logical server
resource, but not necessarily an ASPX file to parse. So the URLs
employed by the pages of an MVC framework-based application have a
custom format that the application itself mandates. In the end, the MVC
framework employs a centralized HTTP handler that recognizes an
application-specific syntax for links. In addition, each addressable
resource exposes a well-known set of operations and a uniform interface
for executing operations.
So, in the MVC world, you do not bother
with the ViewState and Postback any more. And also, the client side
HTML contents will become clean without “client side ID pollution”
troubling you. For this, we are not going to provide related code
illustration, so you can dissect and test yourself according to the
"MVCeProduct" sample project provided in the fourth part of this
tutorial.
(2) More Distinct Separations between the M-V-C
Rather
than the traditional ASP.NET Web Forms under which the controller and
view are within a page (the .aspx corresponds to the View and .aspx.cs
to Controller), by introducing a new REST model, each page in ASP.NET
MVC is split into two distinct components -- Controller and View -- that
operate over the same Model of data. For a clearer understanding,
Figure 2 shows the relationships of the Model, View, and Controller in
the sample application provided with this article series.
Figure 2 -the relationships of the M-V-C in the sample application
Another
important aim of ASP.NET MVC is to ease the TDD. Since in an MVC
project, each component keeps a distinct relationship, this, of course,
simplifies the TDD in some degree. In fact, the main causes easing TDD
are not only limited to this. From the very beginning of designing the
underground infrastructure of the MVC architecture, Microsoft employed
excellent design patterns, which may be the most important cause to ease
TDD—you can unit test each component individually: the View component,
the URL Route, Linq to SQL, the Controller action, etc….