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 end- user 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 ) 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 – ASP.NET MVC – 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 definitionsExamples 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 – extensions/mvc/URLRouting.aspxhttp://quickstarts.asp.net/3-5- extensions/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 life- cycle, and it's not trivial to understand where to put your code. Also because the process logic is tightly coupled with the page life- cycle, 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 web- form 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