Post on 14-May-2015
description
A new “pluggable” web framework
*Asp.Net MVC
Stefano Paluellostefano.paluello@pastesoft.comhttp://stefanopaluello.wordpress.com Twitter: @palutz
*Agenda
*MVC and Asp.Net
*The Model, the View and the Controller (looks like “The Good, the Bad and the Ugly” )
*HtmlHelper and PartialView
*Routing
*Filters
*TDD with Asp.Net MVC
*MVC and Asp.Net
From WebForm to MVC
*Asp.Net
*Asp.Net was introduced in 2002 (.Net 1.0)
*It was a big improvement from the “spaghetti code” that came with Asp classic
*It introduced a new programming model, based on Events, Server-side Controls and “stateful” Form (Session, Cache, ViewState): the RAD/VB-like development model for the web.
*It allowed a lot of developers to deal with the Web, also if they have limited or no skills at all in HTML and JavaScript.
Build with productivity in mind
*Windows Form and Web Form models
Code
Action
Reaction
Server
Server
Serialize/DeserializeWebform state
CodeHttpRequest
HttpResponse
*That’s cool… But
*Events and State management are not HTTP concepts (you need a quite big structure to manage them)
*The page life cycle, with all the events handler, can become really complicated and also delicate (easy to break)
*You have low control over the HTML code generated
*The complex Unique ID values for the server-side controls don’t fit well with Javascript functions
*There is a fake feeling of separation of concerns with the Asp.Net’s code behind
*Automated test could be challenging.
*The Web development today is
*Web standards
*HTTP
*CSS
*Javascript
*REST (Representational State Transfer), represents an application in terms of resources, instead of SOAP, the Asp.Net web service base technology
*Agile and TDD
*So… Welcome, Asp.Net MVC
*Asp.Net MVC “tenets”
*Be extensible, maintainable and flexible
*Be testable
*Have a tight control over HTML and HTTP
*Use convention over configuration
*DRY: don’t repeat yourself
*Separation of concerns
*The MVC pattern
*Separation of concerns
*Separation of concerns comes naturally with MVC
*Controller knows how to handle a request, that a View exist, and how to use the Model (no more)
*Model doesn’t know anything about a View
*View doesn’t know there is a Controller
*Asp.Net > Asp.Net MVC
*Based on the .Net platform (quite straightforward )
*Master page
*Forms authentication
*Membership and Role providers
*Profiles
*Internationalization
*Cache
Asp.Net MVC is built on (the best part of) Asp.Net
*Asp.Net and Asp.Net MVC run-time stack
*DemoFirst Asp.Net MVC application
*Asp.Net MVCThe structure of the project
*Convention over configuration
*Asp.Net MVC projects have some top-level (and core) directories that you don’t need to setup in the config:
*Controllers, where you put the classes that handle the request
*Models, where you put the classes that deal with data
*Views, where you put the UI template files
*Scripts, where you put Javascript library files and scripts (.js)
*Content, where you put CSS and image files, and so on
*App_Data, where you put data files
*Models, Controllers and Views
*The Models
*Classes that represent your application data
*Contain all the business, validation, and data acccess logic required by your application
*Three different kind of Model:
*data being posted on the Controller
*data being worked on in the View
*domain-specific entities from you business tier
*You can create your own Data Model leveraging the most recommend data access technologies
The representation of our data
*An actual Data Model using Entity Framework
4.0
*ViewModel Pattern
*Additional layer to abstract the data for the Views from our business tier
*Can leverage the strongly typed View template features
*The Controller has to know how to translate from the business tier Entity to the ViewModel one
*Enable type safety, compile-time checking and Intellisense
*Useful specially in same complex scenarios
Create a class tailored on our specific View scenarios
*Model vs.ViewModel
public ActionResult Customer(int id)
{
ViewData[“Customer”] = MyRepository.GetCustomerById(id);
ViewData[“Orders”] = MyRepository.GetOrderforCustomer(id);
return View();
}
public class CustomerOrderMV
{
Customer CustomerData { get; set;}
Order CustomerOrders { get; set;}
}
public ActionResult Customer(int id)
{
CustomerOrderMV custOrd = MyRepository.GetCustomerOrdersById(id);
ViewData.Model = custOrd;
return View();
}
*Validation
*Validation and business rule logic are the keys for any application that work with data
*Schema validation comes quite free if you use OR/Ms
*Validation and Business Rule logic can be quite easy too using the Asp.Net MVC 2 Data Annotations validation attributes (actually these attributes were introduced as a part of the Asp.Net Dynamic Data)
Adding Validation Logic to the Models
*Data Annotations validation
[MetadataType(typeof(Blog_Validation))]
public partial class Blog
{
}
[Bind(Exclude = "IdBlog")]
public class Blog_Validation
{
[Required(ErrorMessage= "Title required")]
[StringLength(50, ErrorMessage = "…")]
[DisplayName("Blog Title")]
public String Title { get; set; }
[Required(ErrorMessage = "Blogger required")]
[StringLength(50, ErrorMessage = “…")]
public String Blogger { get; set; }ù
…
}
How to add validation to the Model through Metadata
*DemoAsp.Net MVC Models
*The Controllers
*The controllers are responsible for responding to the user request
*Have to implement at least the IController interface, but better if you use the ControllerBase or the Controller abstract classes (with more API and resources, like the ControllerContext and the ViewData, to build your own Controller)
*My own Controller
* using System;
* using System.Web.Routing;
* namespace System.Web.Mvc
* {
* // Summary: Defines the methods that are required for a controller.
* public interface IController
* {
* // Summary: Executes the specified request context.
* // Parameters:
* // requestContext: The request context.
* void Execute(RequestContext requestContext);
* }
* } * using System.Web;
* using System.Web.Mvc;
* public class SteoController : IController
* {
* public void Execute(System.Web.Routing.RequestContext requestContext)
* {
* HttpResponseBase response = requestContext.HttpContext.Response;
* response.Write("<h1>Hello MVC World!</h1>");
* }
* }
*This reminds me something…
public interface IController
{void Execute(RequestContext requestContext);
}
public interface IHttpHandler
{void ProcessRequest(HttpContext context);
bool IsReusable { get; }
}
*They look quite similar, aren’t they?
*The two methods respond to a request and write back the output to a response
*The Page class, the default base class for ASPX pages in Asp.Net, implements the IHttpHandler.
*The Action Methods
*All the public methods of a Controller class become Action methods, which are callable through an HTTP request
*Actually, only the public methods according to the defined Routes can be called
*The ActionResult
*Actions, as Controller’s methods, have to respond to user input, but they don’t have to manage how to display the output
*The pattern for the Actions is to do their own work and then return an object that derives from the abstract base class ActionResult
*ActionResult adhere to the “Command pattern”, in which commands are methods that you want the framework to perform in your behalf
*The ActionResult
public abstract class ActionResult
{public abstract void ExecuteResult (ControllerContext context);
}
public ActionResult List()
{
ViewData.Model = // get data from a repository
return View();
}
*ActionResult types
*EmptyResult
*ContentResult
*JsonResult
*RedirectResult
*RedirectToRouteResult
*ViewResult
*PartialViewResult
*FileResult
*FilePathResult
*FileContentResult
*FileStreamResult
*JavaScriptResult
Asp.Net MVC has several types to help handle the response
*DemoAsp.Net MVC Controllers
*The Views
*The Views are responsible for providing the User Interface (UI) to the user
*The View receive a reference to a Model and it transforms the data in a format ready to be presented
*Asp.Net MVC’s View
*Handles the ViewDataDictionary and translate it into HTML code
* It’s an Asp.Net Page, deriving from ViewPage (System.Web.Mvc.ViewPage) which itself derives from Page (System.Web.UI.Page)
*By default it doesn’t include the “runat=server”, that you can add by yourself manually, if you want to use some server controls in your View (better to use only the “view-only” controls)
*Can take advantage of the Master Page, building Views on top of the Asp.Net Page infrastructure
* Asp.Net MVC Views’ syntax
*You will use <%: %> syntax (often referred to as “code nuggets”) to execute code within the View template.
* There are two main ways you will see this used:
*Code enclosed within <% %> will be executed
*Code enclosed within <%: %> will be executed, and the result will be output to the page
*DemoViews, Strongly Typed View, specify a View
*Html Helpers
*Html.Encode
*Html.TextBox
*Html.ActionLink, RouteLink
*Html.BeginForm
*Html.Hidden
*Html.DropDownList
*Html.ListBox
*Html.Password
*Html.RadioButton
*Html.Partial, RenderPartial
*Html.Action, RenderAction
*Html.TextArea
*Html.ValidationMessage
*Html.ValidationSummary
Methods shipped with Asp.Net MVC that help to deal with the HTML code.
MVC2 introduced also the strongly typed Helpers, that allow to use Model properties using a Lambda expression instead of a simple string
*Partial View
*Asp.Net MVC allow to define partial view templates that can be used to encapsulate view rendering logic once, and then reuse it across an application (help to DRY-up your code)
*The partial View has a .ascx extension and you can use like a HTML control
*Partial View Example
*The default Asp.Net MVC project just provide you a simple Partial View: the LogOnUserControl.ascx
<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
<%
if (Request.IsAuthenticated) {
%>
Welcome <b><%: Page.User.Identity.Name %></b>!
[ <%: Html.ActionLink("Log Off", "LogOff", "Account") %> ]
<%
}
else {
%>
[ <%: Html.ActionLink("Log On", "LogOn", "Account") %> ]
<%
}
%>
A simple example out of the box
*Ajax
*You can use the most popular libraries:
*Microsoft Asp.Net Ajax
* jQuery
*Can help to partial render a complex page (fit well with Partial View)
*Each Ajax routine will use a dedicated Action on a Controller
*With Asp.Net Ajax you can use the Ajax Helpers that come with Asp.Net MVC:
*Ajax.BeginForm
*AjaxOptions
* IsAjaxRequest
*…
It’s not really Asp.Net MVC but can really help you to boost your MVC application
*Routing
*Routing in Asp.Net MVC are used to:
*Match incoming requests and maps them to a Controller action
*Construct an outgoing URLs that correspond to Contrller action
How Asp.Net MVC manages the URL
*Routing vs URL Rewriting
*They are both useful approaches in creating separation between the URL and the code that handles the URL, in a SEO (Search Engine Optimization) way
*URL rewriting is a page centric view of URLs (eg: /products/redshoes.aspx rewritten as /products/display.aspx?productid=010)
*Routing is a resource-centric (not only a page) view of URLs. You can look at Routing as a bidirectional URL rewriting
*Defining Routes
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults );
}
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
RegisterRoutes(RouteTable.Routes);
}
}
The default one…
*Route URL patterns
*StopRoutingHandler and IgnoreRoute
*You can use it when you don’t want to route some particular URLs.
*Useful when you want to integrate an Asp.Net MVC application with some Asp.Net pages.
*Filters
*Filters are declarative attribute based means of providing cross-cutting behavior
*Out of the box action filters provided by Asp.Net MVC:
*Authorize: to secure the Controller or a Controller Action
*HandleError: the action will handle the exceptions
*OutputCache: provide output caching to for the action methods
*DemoA simple Filter (Session Expire)
*TDD with Asp.Net MVCAsp.Net MVC was made with TDD in mind, but you can use also without it (if you want… )
*A framework designed with TDD in mind from the first step
*You can use your favorite Test Framework
*With MVC you can test the also your UI behavior (!)
*DemoTDD with Asp.Net MVC
*Let’s start the Open Session:
Asp.Net vs. Asp.Net MVC