CTTDNUG ASP.NET MVC

Editor's Notes

• #2: Abstract: Duration: 1 hour Level: 200
• #4: Estimated Time: 2 minutes Talking Points: In this session we’ll take a look at WebForms and how its request pipeline is structured, and then introduce the MVC pattern, and how it is implemented into the ASP.NET MVC framework. We’ll then discuss how WebForms and MVC differ from each other. Then we’ll look into the default conventions and project structure of an MVC application.
• #6: Estimated Time: 2 minutes For the entire life of ASP.NET it has been seen as a single framework that included both runtime and presentational aspects. This includes core features such as roles and globalization, as well as WebForms features such as master pages and user controls.
• #7: Estimated Time: 3 minutes Talking Points: In WebForms today you start out with an ASPX page… [Advance Animation] Within the page you can have any number of user controls, custom controls, and server controls. [Advance Animation] In addition, a page can have a master page, which can in turn have any number of controls itself. [Advance Animation] When you introduce model data, due to the level of abstraction needed by WebForms, any of the components used can access to data [Advance Animation] The page, the master page, and any of their individual controls contain logic that both retreives model data and contains it view representation. This is model that has made WebForms so successful and useful for web developers.
• #9: Estimated Time: 2 minutes Talking Points: WebForms uses a pattern called page controller. When a request comes into ASP.NET.. [Advance Animation] , 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.
• #10: Estimated Time: 2 minutes The level of abstraction that WebForms provides has a lot of benefits to it, but it doesn’t provide any framework-level guidance in terms of what should do what and when. Between your pages, master pages, user controls, server controls, and custom controls, you can end up with a mixture of HTML, data access code, and business logic. There are certainly methodologies/practices that can be employed with WebForms that can remedy that, but it becomes an implementation task of the developer, since the framework doesn’t provide any of that separation/guidance.
• #11: Estimated Time: 2 minutes The control abstractions that WebForms provides are very powerful in that they neatly contain all of the UI and business logic needed so you can just place them within a page and go. The adverse side of that is that it can end up hiding complexity that you’d rather have control over. A common problem is viewstate [Advance Animation] . It isn’t viewstate’s fault that things like this can happen, but it can be very easy to consume a control that could end up hurting the performance of your application. In addition, many times the markup rendered by server controls aren’t always ideal and there is little control over that without having to redo its rendering completely.
• #12: Estimated Time: 1 minute It is possible to test a WebForms application, but it isn’t easy enough. There isn’t enough prescriptive guidance around how to do it properly, and for many it requires more effort than it is worth. For unit testing to truly become mainstream and approachable, testability has to be a prime concern of the framework being used, such that writing tests against applications written with it is easy.
• #13: Estimated Time: 1 minute WebForms has been the only option on the ASP.NET stack and provides a mature product that has proven successful for lots of developers. But it does have some weaknesses.
• #15: Estimated Time: 2 minutes With the release of .NET Framework 3.5 SP1, ASP.NET started being seen as more modular. ASP.NET Core now represents just the runtime aspects of ASP.NET, and ASP.NET WebForms is simply a presentation option that sits on top of that runtime. With this, it becomes possible to introduce other presentation layer implementations on top of ASP.NET, such as the new ASP.NET MVC framework. While many who are beginning to investigate into ASP.NET MVC think that it is the replacement for WebForms, as you can see, it is simply another option for developing web applications using the ASP.NET runtime.
• #16: Estimated Time: 1 minute What is it about ASP.NET MVC that differentiates itself from WebForms? What value propositions does it provide and how does it benefit users? The primary thing is that it embraces the MVC pattern at the architectural level, and is generally just about getting out of the way of the developer, allowing you to have full control over the areas you want/need to.
• #17: Estimated Time: 2 minutes MVC is a design pattern that stands for Model-View-Controller. What is strives to do is separate the concerns of an application’s presentation layer by assigning specific roles to the three different components. The Controller is responsible for handling all user input. Once input has been received, the Controller will perform any operations/actions it needs to, which might include interacting with the Model. The Model represents the core concern/logic of the application. Once the Controller retrieves some model data and performs any work with the model/etc it needs to it constructs a presentation model that describes the model in terms the View can understand. The View is the visual representation of the model. It presents the model data to the actual user in a way that is meaningful. In a web application, this would typically be HTML. With these three pieces in place, your presentation layer becomes cleanly separated in such a way that each component can be developed/tested independently. Estimated Time: 2 minutes Talking Points: MVC or Model-View-Controller 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 controller is responsible for interacting with the model, and then passing that data down to the view. The view’s sole responsibility is acting as a representation of the model data it is given by the controller.
• #18: Estimated Time: 4 minutes Talking Points: So now let’s see how a typical ASP.NET MVC application contrasts to the way a WebForms application looked. Notice that we still have our ASPX page, which in turn can leverage user controls, custom controls, and server controls. Nothing difference there. [Advance Animation] 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… [Advance Animation] With WebForms, any of the controls, or page, or master page was directly interacting with the model [Advance Animation] We introduce the controller into the picture, which will now be the orchestrator between the model and the views [Advance Animation] Here, instead of the pages and controls directly accessing the model, the controller is strictly doing that. Once it gets the model data… [Advance Animation] it is responsible for passing the data to the page, or view.
• #19: MGB 2003 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Estimated Time: 4 minutes So what does MVC look like when implemented over the web? Talking Points: When we looked at WebForms, we saw that it 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, [Advance Animation] the request is routed to a controller object [Advance Animation] The controller then accesses the model data, if model data is needed [Advance Animation] The controller then takes the model data and passes in to the view, which then serves the request. When an HTTP request comes into the application it is mapped to a controller. Remember as we mentioned in the previous slide, in the MVC design pattern, the controller is the piece of the trifecta that handles all user input. In the case of a web application, user input is represented as HTTP requests [Advance Animation] . Once the controller has received input, it performs whatever operations it needs to and then assembles a presentation model [Advance Animation] . The controller then takes the model and passes it off to the view. Remember that the view is simply a visual representation of the model [Advance Animation] . The view then “transforms” the model into whatever format it uses to represent it. In a web application, this would typically be HTML [Advance Animation] . The view then serves the request by responding with its visual representation.
• #20: MGB 2003 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Estimated Time: 3 minutes The primary framework goals of ASP.NET MVC are… The main tenets of ASP.NET MVC are… 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 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 get be easily discovered. Frictionless testability – By “frictionless” I mean that when you want to test your code, the framework it was written it doesn’t cause you friction. This is very important if you want to seriously perform long-term unit testing on an application, because if developers were constantly running into points of friction when trying to test, they would eventually abandon it. Tight cover over markup – ASP.NET MVC doesn’t contain any server controls or high-level abstractions that mask their underlying rendering. When you develop an ASP.NET MVC application, you have complete control over the markup. ASP.NET MVC does include some HTML helpers that “hide” away some HTML, but they are at the most basic level of rendering (i.e. just an <input> element). Leverage the benefits of ASP.NET – Because ASP.NET MVC is built on top of the core ASP.NET runtime, you still have plenty of old-friends that can be used (i.e. profiles, membership, roles, caching). All of the same intrinsics you’ve always known are still valid and used heavily. Conventions and guidance – ASP.NET MVC comes with a set of predefined conventions that make the use of it much easier, without the need to for tons of configuration. It also provides framework-level guidance. The idea is that ASP.NET MVC wants to try to lead developers down the pit of success.
• #21: Estimated Time: 4 minutes Talking Points: Here we see an example of the default project structure of an ASP.NET MVC application. Because ASP.NET MVC comes packaged with a set of default conventions, it’s important to understand those conventions, and even better how you can override them if you want [Advance Animation] Here we see the controllers, placed in the Controllers folder. You actually don’t have to place your controllers in this folder, but it is created for you by default, and is considered a pretty standard place for them [Advance Animation] The ASP.NET MVC project templates places a folder called Models in your project that can be used to contain your model classes. This is only one option for model placement, and shouldn’t be seen as guidance that this is the “right way” to do it. Your model classes are in no way coupled to their placement, so you can put them in a different folder, or even in another project if you want [Advance Animation] Views in an ASP.NET MVC application are by default located in the Views folder. Within the Views folder, there are two options to place your views: Either underneath the Shared folder, which are views that are meant to be used by multiple controllers. These are typically user controls or master pages. Or underneath a folder named after the Controller they are associated to. These are views that are specific to controllers. This is the default convention, but it can be changed if you want. We’ll go into customizing this in the next session [Advance Animation] The route definitions that map URL patterns to your controllers are declared within your application’s Global.asax file. This way they can be created upon Application Start.
• #23: Estimated Time: 2 minutes Talking Points: Now’s let’s briefly discuss the differences between WebForms and ASP.NET MVC. While MVC is built on top of ASP.NET, it doesn’t have… Postbacks 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.
• #24: Estimated Time: 2 minutes Talking Points: Just to reiterate the point that MVC is built on top of ASP.NET, let’s briefly discuss the similarities… Web designer Master pages User controls Membership/Roles/Profile providers Globalization Caching The HTTP intrisincs
• #27: MGB 2003 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Estimated Time: 2 minutes Since ASP.NET MVC is so tightly integrated with the ASP.NET Routing engine, it is simple to take control over the URLs that your application exposes. As such, you shouldn’t have to settle for poor URLs that are simply based on the organization of your application’s internals. You should design your sitemap to be as intuitive as you want. When you do this, users will be happier, and so will search engines.
• #29: Estimated Time: 2 minutes Talking Points: There are a lot of conventions centered around your controllers 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.
• #30: Estimated Time: 10 minutes This demo is meant to show how to write some simple unit tests against the controller(s) written in the previous demo. It should illustrate how to successfully test actions that are for GET and POST scenarios. It should also includes some examples of how to test your route definitions.
• #31: Estimated Time: 5 minutes Talking Points: While ASP.NET MVC provides a strong offering of functionality out of the box, there will be developers that don’t like some of its default behavior or conventions. Luckily for them they can easily replace anything in the execution pipeline they don’t care for with their own implementation. Because ASP.NET MVC employs separations of concerns throughout its entire API, every task has specific representation that can easily be tweaked/replaced, without having to affect anything else around it. This diagram illustrates the lifecycle of an MVC request, after the URL routing engine has executed. It starts with the ControllerBuilder, that is responsible for tracking which controller factory type or instance should be used [Advance Animation] The controller builder returns an instance of the controller factory. If no specific controller factory was specified, then it will return an instance of the DefaultControllerFactory class. The controller factory is responsible for creating instances of controllers [Advance Animation] The controller factory creates the requested controller, and the controller’s Execute method is called [Advance Animation] The controller calls into the controller action invoker, which is responsible for actually executing the requested action method, and… [Advance Animation] Action filters allow you to have pre and post logic that runs before and after the actual action method executes. Hence, the controller action invoker executes any action filter’s pre-actions, and then… [Advance Animation] Then the invoker executes the actual action method on the controller. The invoker then executes any action filter’s post-actions [Advance Animation] The invoker then takes the ActionResult instance returned from the action method and calls its ExecuteResult method. At this point, it depends on the type of action result returned from the action method that determines what occurs. Since the RenderViewResult is the most common action result type, we’ll examine the pipeline from the perspective of its use [Advance Animation] The RenderView method is called on the view engine that is associated with the controller [Advance Animation] The view engine uses its view locator to retrieve the path of the requested view, and optionally its master page, if the requested view was a page and not a user control [Advance Animation] The view engine takes the returned view paths to instantiate an instance of the requested view, and then calls RenderView on the view, which then renders the view, responding to the user. Note: The view engine is only required to implement the IViewEngine interface which simply has a RenderView method. Hence, the view locator dependency isn’t really a required part of the pipeline. In this example, we’re illustrating the use of the WebFormViewEngine, and its WebFormViewLocator.
• #33: Estimated Time: 5 minutes Talking Points: Action filters allows you to apply pre and post code that will be executed before and after an action method’s execution, and before and after the action result’s execution. All action filters must implement the IActionFilter interface. The Controller class itself implements IActionFilter, and therefore provides overrideable methods that can be used to provide controller level filters. In addition, the ActionFilterAttribute provides a base-class for creating an attribute that can be applied at either the controller or action level. Since you can stack any number of ActionFilterAttributes on a controller or action method, the class provides an Order property that you can provider an execution order of the filters. The order of execution for action filters are as follows: The overridden filter methods of the controller Any action filter applied at the controller level, in the order specified. Any action filters applied at the action level, in the order specified. If no orders are specified for the action filters, they will be executed bottom-up. This applies to both controller and action level filters.
• #34: Estimated Time: 5 minutes Talking Points: The controller factory’s sole responsibility is creating an instance of a requested controller. A controller factory must implement the IControllerFactory, which has two methods: CreateController DisposeController A default implementation of the IControllerFactory interface is provided in the DefaultControllerFactory class. It simply takes the requested controller name, appends “Controller” to it, and then instantiates an instance of the type with the name [ControllerName]Controller. This behavior is pretty standard and for most scenarios might work out great. So when would you need to create your own controller factory? Since it is the framework that creates controller instances for you, if you need to inject some dependencies into your controllers, they have to be done by a controller factory. These can be in the form of a constructor parameter, or even properties that you want set to a default value. Hence, a controller factory is a perfect place for putting DI/IoC logic that retrieves instances of controllers from a DI container, instead of just instantiating an instance normally. When you’ve created a controller factory, you can associate it when the runtime by calling ControllerBuilder.SetControllerFactory from within your Application’s Start event in the Global.asax file. This way, the pipeline will get an instance of your controller factory when it needs to create a controller.
• #35: Estimated Time: 5 minutes Talking Points: The view engine only comes into play when a controller action responds with a RenderViewResult (that is with the four ActionResult types provided out of the box). When a controller renders a view, it is the view engines job to locate the requested view, and then run whatever logic is required to render it to the user. View engines must implement the IViewEngine interface, and include a single method: RenderView. The view engine is associated with a controller through the Controller class’s ViewEngine property. By default, the Controller class uses the WebFormViewEngine, which is responsible for rendering views that use the WebForms templating syntax, which includes: ASPX pages, ASCX user controls, and master pages. How is it that a view engine can take a view name, such as “Index”, and convert that into an ASPX page? This is where the view locator comes in. The view locators responsibility is locating a view by name. The WebFormViewEngine uses the WebFormViewLocator which looks for the requested view under the Views folders and subsequently under a subfolder named after the controller (or the Shared folder). A view locator must implement the IViewLocator interface, which contains two methods: GetViewLocation, and GetMasterLocation. The ViewLocator class provides a good implementation of IViewLocator that can be used as a base class for new custom view locators, instead of implementing IViewLocator directly. The WebFormViewLocator inherits from ViewLocator, and simply sets the ViewLocationFormats and MasterLocationFormats properties from its constructor. So why would you ever use a different view engine? If you wanted to use a different view language or syntax other than WebForms. There are numerous templating languages already available that provide a view engine: NHaml, Brail, NVelocity. Because the view engine must be set on the controller instance, a common scenario is to create a custom controller factory that sets the created controller instance’s view engine to the desired type, that way every created controller will render its view using the custom view engine. If you wanted to override the view engine for a specific action, you could also set the ViewEngine property in the action method before returning the action result.
• #48: Estimated Time: 2 minutes Talking Points: In summary… We showed the current state of affairs in WebForms, introduced the MVC pattern, and showed how ASP.NET MVC builds on top of WebForms and implements MVC to provide an alternative web application framework. We discussed the differences and similarities between WebForms and MVC. Finally, we highlighted the default conventions associated with an MVC application, and show the project structure.