ASP.NET and
Model View Control
Jesper Tørresø
ITNET2
F08
Turns around the usual way
• A MVC Controller takes control over from the standard
ASP.NET Framework View Engine.
• From Scott Guthrie
– ”The MVC framework supports using the existing ASP.NET
.ASPX, .ASCX, and .Master markup files as "view templates"
(meaning you can easily use existing ASP.NET features like
nested master pages, <%= %> snippets, declarative server
controls, templates, data-binding, localization, etc). It does
not, however, use the existing post-back model for
interactions back to the server. Instead, you'll route all enduser interactions to a Controller class instead - which helps
ensure clean separation of concerns and testability (it also
means no viewstate or page lifecycle with MVC
based views). ”
But what about the existing
ASP.NET framework?
• May we ”only” use HTML control and not
server controls and/oe user controls?
• All HTML from controls may be used
• We can use the already known APS.NET
server controls and also a special MVC
User Control. (!!!!)
• But we must take care of routing etc by
our self.
Model View Control
JSP Model 1 architecture (from 1998-1999)
Is this original ASP.NET ?
Model View Control
JSP Model 2 architecture
Model, View and Controller:
The pattern MVC, which stands for Model-View-Controller, separates
an application in three components:
• Model: this is where all the business logic of the application resides:
it can range from a simple static class that returns a dataset to a
complex multi-assembly Business Logic Layer that uses an
assembly specific to the Data Access Layer.
• View: at the other end of the application is the View, which displays
the application's user interface and contains the representation of
the data that have been retrieved by the Model. This doesn't have
logic, other than the one strictly related to the presentation of data.
• Controller: between the two components stands the Controller. It
acts as the orchestrator of all the interactions among the other
components and the users: it handles the requests, reads the form
values, passes them to the Model, decides which View to render
and finally sends the data to be rendered to the View.
Interaction
1. The request comes from the client
and hits the Controller.
2. The Controller calls the Model in
order to perform some "business"
operations.
3. The Model returns the results of the
operations back to the Controller.
4. The Controller decides which View
needs to be rendered and sends it
the data that must be rendered.
5. Finally the View renders the output
and sends the response back to the
client.
Model 2 and ASP.NET
URL Routning
• Normal ASP.NET
– http://server/application/Products.aspx?id=4
• ASP.NET MVC
– http://server/application/Products/show/beverages
• The URL’s are interpreted by a
RouteHandler and known as routes to the
Controller.
URL Routning 1
• The URL patterns defined are called
routes Ex:
Valid route definitions
Examples of matching URL
{controller}/{action}/{id}
/Products/show/beverages
{table}/Details.aspx
/Products/Details.aspx
blog/{action}/{entry}
/blog/show/123
{reporttype}/{year}/{month}/{day} /sales/2008/1/5
Typically, you add routes in the handler for the
Application_Start event in the Global.asax file. This approach
makes sure that the routes are available when the application
starts.
URL Routning 2
• Initiating application in Global.asax.cs
void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}
public static void RegisterRoutes(RouteCollection routes)
{
routes.Add(new Route ( "Category/{action}/{categoryName}"
new CategoryRouteHandler() )
{
Defaults = new RouteValueDictionary
{{"categoryName", "food"}, {"action", "show"}}
}
);
}
URL Routning 3
• See more here
– http://quickstarts.asp.net/3-5extensions/mvc/URLRouting.aspx
• Setting default values in Routes
• Adding constraints Routes
• Making a MVC route to a URL
Sow! What is ASP.NET MVC?
• ASP.NET MVC is a framework that allows developers to apply the
MVC pattern in the development of an ASP.NET application, thus
allowing a better separation of concerns, which results in better
reusability and easier testing.
• MVC was one of the concepts originally found in SmallTalk. MVC
and the web seem like a match made in heaven and allow for a
simple way of building complex web applications.
• To understand why this recently re-discovered way of building web
application was developed, we need to have a look at the pitfalls of
the standard model, which is the web-form approach.
– First, it is event based: it can be good or bad depending on how you
look at it. Good because it helps VB6 and WinForms developers to
smoothly migrate their skills to the web application development. Bad
because there are dozens of events that are raised during the page lifecycle, and it's not trivial to understand where to put your code. Also
because the process logic is tightly coupled with the page lifecycle, it is difficult to test using automated tests. Cont..
Sow! What is ASP.NET MVC? cont.
– It also uses server forms and ViewState: again, as with the event based
model, it can be good since this hides to the developer all the problems related
to maintaining the state of the page (values of textboxes, contents of dropdowns
and so on), but can also be bad if you want to control exactly how the page is
rendered, and you don't need to maintain all the state.
– Furthermore, it uses server controls: good because they render the HTML for
you; bad since they render it the way they want.
•
•
With the MVC framework you gain back the control of the order in which
things happen during the page life-cycle, of the way state is persisted
between requests, and the code with which HTML is rendered. And thanks
to a better separation of concerns it's easier to test the process logic. But
all this control has a cost: you have to do everything by yourself.
Keep in mind this: the MVC framework is not a replacement for the webform programming model, but it's an alternative programming model, for
those who want to have a better control and want to be able to also test the
presentation logic