@foreach(var bid in bids) {
@bid.Username
@bid.Amount
}
Last Bid Amount: @bid.Amount
Code blocks are a means to execute code within a template and do not render anything to the view. In direct contrast to the way that code nuggets must provide a return value for the view to render, the view will completely ignore values that a code block returns.
Layouts
Razor offers the ability to maintain a consistent look and feel throughout your entire website through layouts. With layouts, a single view acts as a template for all other views to use, defining the site-wide page layout and style.
A layout template typically includes the primary markup (scripts, CSS stylesheets, and structural HTML elements such as navigation and content containers), specifying lo cations within the markup in which views can define content. Each view in the site then refers to this layout, including only the content within the locations the layout has indicated.
Take a look at a basic Razor layout file (_Layout.cshtml):
28 | Chapter 1: Fundamentals of ASP.NET MVC
@View.Title
@RenderSection("Header")
@RenderBody()
The layout file contains the main HTML content, defining the HTML structure for the entire site. The layout relies on variables (such as @View.Title) and helper functions like @RenderSection([Section Name]) and @RenderBody() to interact with individual views.
Once a Razor layout is defined, views reference the layout and supply content for the sections defined within the layout.
The following is a basic content page that refers to the previously defined _Layout.cshtml file:
@{ Layout = "~/_Layout.cshtml"; }
@section Header {
EBuy Online Auction Site
}
@section Footer {
Copyright @DateTime.Now.Year
}
This is the main content.
Razor layouts and the content views that depend on them are assembled together like puzzle pieces, each one defining one or more portions of the entire page. When all the pieces get assembled, the result is a complete web page.
Views | 29
Partial Views
While layouts offer a helpful way to reuse portions of markup and maintain a consistent look and feel throughout multiple pages in your site, some scenarios may require a more focused approach.
The most common scenario is needing to display the same high-level information in multiple locations in a site, but only on a few specific pages and in different places on each of those pages.
For instance, the Ebuy auction site may render a list of compact auction details— showing only the auction’s title, current price, and perhaps a thumbnail of the item— in multiple places in the site such as the search results page as well as a list of featured auctions on the site’s homepage.
ASP.NET MVC supports these kinds of scenarios through partial views.
Partial views are views that contain targeted markup designed to be rendered as part of a larger view. The following snippet demonstrates a partial view to display the com pact auction details mentioned in the scenario above:
@model Auction
To render this snippet as a partial view, simply save it as its own standalone view file (e.g. /Views/Shared/Auction.cshtml) and use one of ASP.NET MVC’s HTML Helpers —Html.Partial()—to render the view as part of another view.
To see this in action, take a look at the following snippet, which iterates over a collection of auction objects and uses the partial view above to render the HTML for each auction:
@model IEnumerable
Search Results
@foreach(var auction in Model) {
@Html.Partial("Auction", auction)
}
Notice that the first parameter to the Html.Partial() helper method is a string con taining the name of the view without its extension.
This is because the Html.Partial() helper method is just a simple layer on top of ASP.NET MVC’s powerful view engine, which renders the view very similar to what occurs after a controller action calls the View() method to return a view action result: the engine uses the view name to locate and execute the appropriate view.
30 | Chapter 1: Fundamentals of ASP.NET MVC
In this way, partial views are developed and executed almost exactly like any other kind of view. The only difference is that they are designed to be rendered as part of a larger view.
The second parameter (auction in the example above) accepts the partial view’s model, just like the model parameter in the View(_View Name_, _[Model]_) controller helper method. This second model parameter is optional; when it’s not specified, it defaults to the model in the view from which the Html.Partial() helper was called. For instance, if the second auction parameter were omitted in the example above, ASP.NET MVC would pass the view’s Model property (of type IEnumerable) in its place.
The examples above show how partial views can provide reusable sec
tions of markup that can help reduce duplication and complexity in your
views.
Though useful, this is only one way to take advantage of partial views—
“Partial Rendering” on page 111 shows how to take advantage of partial
views to provide a simple and effective way to enhance your site with
AJAX.
Displaying Data
The MVC architecture depends on the model, view, and controller all remaining sep arate and distinct, while still working together to accomplish a common goal. In this relationship, it is the controller’s job to be the “traffic cop,” coordinating various parts of the system to execute the application’s logic. This processing typically results in some kind of data that needs to be relayed to the user. Alas, it is not the controller’s job to display things to the user—that is what views are for! The question then becomes, how does the controller communicate this information to the view?
ASP.NET MVC offers two ways to communicate data across model-view-controller boundaries: ViewData and TempData. These objects are dictionaries available as proper ties in both controllers and views. Thus, passing data from a controller to a view can be as simple as setting a value in the controller, as in this snippet from HomeController.cs:
public ActionResult About()
{
ViewData["Username"] = User.Identity.Username;
ViewData["CompanyName"] = "EBuy: The ASP.NET MVC Demo Site";
ViewData["CompanyDescription"] =
"EBuy is the world leader in ASP.NET MVC demoing!";
return View("About");
}
and referencing the value in the view, as in this portion of the About.cshtml file: Views | 31
@ViewData["CompanyName"]
@ViewData["CompanyDescription"]
Cleaner access to ViewData values via ViewBag
ASP.NET MVC controllers and views that expose the ViewData property also expose a similar property named ViewBag. The ViewBag property is simply a wrapper around the ViewData that exposes the ViewData dictionary as a dynamic object.
For example, any references to values in the ViewData dictionary in the preceding snip pets can be replaced with references to dynamic properties on the ViewBag object, as in:
public ActionResult About()
{
ViewBag.Username = User.Identity.Username;
ViewBag.CompanyName = "EBuy: The ASP.NET MVC Demo Site";
ViewBag.CompanyDescription = "EBuy is the world leader in ASP.NET MVC demoing!";
return View("About");
}
and:
@ViewBag.CompanyName
@ViewBag.CompanyDescription
View models
In addition to its basic dictionary behavior, the ViewData object also offers a Model property, which represents the primary object that is the target of the request. Though the ViewData.Model property is conceptually no different from ViewData["Model"], it promotes the model to a first-class citizen and recognizes it as more important than the other data that might be in the request.
For example, the previous two snippets showed that the CompanyName and CompanyDe scription dictionary values are clearly related to each other and represent a great opportunity to wrap together in a model.
Take a look at CompanyInfo.cs:
public class CompanyInfo
{
public string Name { get; set; }
public string Description { get; set; }
}
the About action in HomeController.cs:
public ActionResult About()
{
ViewBag.Username = User.Identity.Username;
var company = new CompanyInfo {
Name = "EBuy: The ASP.NET MVC Demo Site",
32 | Chapter 1: Fundamentals of ASP.NET MVC
Description = "EBuy is the world leader in ASP.NET MVC demoing!", };
return View("About", company);
}
and this snippet from About.cshtml:
@{ var company = (CompanyInfo)ViewData.Model; }
@company.Name
@company.Description
In these snippets, the references to the CompanyName and CompanyDescription dictionary values have been merged into an instance of a new class named CompanyInfo (com pany). The updated HomeController.cs snippet also shows an overload of the View() helper method in action. This overload continues to accept the name of the desired view as the first parameter. The second parameter, however, represents the object that will be assigned to the ViewData.Model property.
Now, instead of setting the dictionary values directly, company is passed as the model parameter to the View() helper method and the view (About.cshtml) can get a local reference to the company object and access its values.
Strongly typed views
By default, the Model property available within Razor views is dynamic, which means that you are able to access its values without needing to know its exact type.
However, given the static nature of the C# language and Visual Studio’s excellent In telliSense support for Razor views, it is often beneficial to specify the type of the page’s model explicitly.
Luckily, Razor makes this pretty easy—simply use the @model keyword to indicate the model’s type name:
@model Auction
@Model.Name
@Model.Description
This example modifies the previous Auction.cshtml example, avoiding the need to add an intermediary variable to cast the ViewData.Model into. Instead, the first line uses the @model keyword to indicate that the model’s type is CompanyInfo, making all references to ViewData.Model strongly typed and directly accessible.
HTML and URL Helpers
The primary goal of most web requests is to deliver HTML to the user, and as such, ASP.NET MVC goes out of its way to help you create HTML. In addition to the Razor markup language, ASP.NET MVC also offers many helpers to generate HTML simply
Views | 33
and effectively. The two most important of these helpers are the HtmlHelper and Url Helper classes, exposed in controllers and views as the Html and Url properties, respectively.
Here are some examples of the two helpers in action:
![](@Url.Content("~/Content/images/header.jpg"))
@Html.ActionLink("Homepage", "Index", "Home")
The rendered markup looks like this:
Homepage
For the most part, the HtmlHelper and UrlHelper types don’t have many methods of their own and are merely shims that the framework attaches behaviors to via extension methods. This makes them an important extensibility point, and you’ll see references to the two types throughout this book.
Though there are far too many methods to list in this section, the one thing to take away at this point is: the HtmlHelper class helps you generate HTML markup and the UrlHelper class helps you generate URLs. Keep this in mind, and turn to these helpers anytime you need to generate URLs or HTML.
Models
Now that we’ve covered controllers and views, it’s time to complete the definition of MVC by discussing models, which are usually considered the most important part of the MVC architecture. If they are so important, why are they the last to be explained? Well, the model layer is notoriously difficult to explain because it is the layer that contains all of the business logic for the application—and that logic is different for every application.
From a more technical standpoint, the model typically consists of normal classes that expose data in the form of properties and logic in the form of methods. These classes come in all shapes and sizes, but the most common example is the “data model” or “domain model,” whose primary job is to manage data.
For example, take a look at the following snippet, which shows the Auction class—the model that will drive the entire EBuy reference application:
public class Auction
{
public long Id { get; set; }
public string Title { get; set; }
public string Description { get; set; }
public decimal StartPrice { get; set; }
public decimal CurrentPrice { get; set; }
public DateTime StartTime { get; set; }
public DateTime EndTime { get; set; }
}
34 | Chapter 1: Fundamentals of ASP.NET MVC
Though we will add various functionality such as validation and behavior to the Auc tion class throughout this book, this snippet is still very representative of a model in that it defines the data that makes up an “auction.”
And, just as we will build on the Auction class throughout the book, be on the lookout for more kinds of classes (such as services and helpers) that all work together to make up the “Model” in “MVC.”
Putting It All Together
So far we’ve described all the parts that make up an ASP.NET MVC application, but the discussion has focused on the code that Visual Studio generates for us as part of the project template. In other words, we haven’t actually made anything yet. So let’s change that!
This section will focus on how to implement a feature from scratch, creating everything you need to accomplish an example scenario: displaying an auction. As a recap, every ASP.NET MVC request requires at least three things: a route, a controller action, and a view (and, optionally, a model).
The Route
To figure out the routing pattern that you’d like to use for a given feature, you must first determine what you’d like your URL for that feature to look like. In this example we are going to choose a relatively standard URL of Auctions/Details/[Auction ID]; for example, http://www.ebuy.biz/Auctions/Details/1234.
What a nice surprise—the default route configuration already supports this URL!
The Controller
Next, we’ll need to create a controller to host the actions that will process the request.
Since controllers are merely classes that implement the ASP.NET MVC controller interface, you could manually add a new class to the Controllers folder that derives from System.Web.Mvc.Controller and begin adding controller actions to that class. However, Visual Studio offers a bit of tooling to take most of the work out of creating new controllers: simply right-click on the Controllers folder and choose the Add > Con troller... menu option, which will pop up the Add Controller dialog shown in Figure 1-8.
Putting It All Together | 35
Figure 1-8. Adding a controller to an ASP.NET MVC application
The Add Controller dialog begins by asking for the name of the new controller class (in this case, we’ll call it AuctionsController) and follows up by asking which scaffold ing template you’d like to use, along with providing a set of options to give you a little bit of control over how ASP.NET MVC is going to generate the new controller class.
Controller templates
The Add Controller dialog offers several different controller templates that can help you get started developing your controllers more quickly:
Empty MVC controller
The default template (“Empty MVC controller”) is the simplest one. It doesn’t offer any customization options because, well, it’s too simple to have any options! It merely creates a new controller with the given name that has a single generated action named Index.
MVC controller with read/write actions and views, using Entity Framework The “MVC controller with read/write actions and views, using Entity Framework” template is just as impressive as it sounds. This template starts with the same output as the “MVC controller with empty read/write actions” template (see below) and then kicks it up a notch, generating code to help you access objects stored in an Entity Framework context and even generating Create, Edit, Details, and Delete views for those objects! This template is a great kick-start when your project uses Entity Framework to access your data, and in some cases the code it generates may be all that you need to support the Read, Edit, Update, and Delete operations for that data.
36 | Chapter 1: Fundamentals of ASP.NET MVC
MVC controller with empty read/write actions
The next option—“MVC controller with empty read/write actions”—generates the same code as the “Empty MVC controller” template, but adds a few more actions that you’ll most likely need in order to expose standard “data access” op erations: Details, Create, Edit, and Delete.
API controller templates
The final three templates—“Empty API controller,” “API controller with empty read/write actions,” and “API controller with read/write actions and views, using Entity Framework”—are the Web API counterparts to the MVC controller tem plates of the same names. We will cover these templates in more detail when we discuss ASP.NET MVC’s Web API functionality in Chapter 6.
An interesting thing to notice about the controller code that Visual Stu
dio generates is that the Index and Details actions each have only one
method, while the Create, Edit, and Delete actions each have two over
loads—one decorated with an HttpPost Attribute, and one without.
This is because Create, Edit, and Delete all involve two requests in order
to complete: the first request returns the view that the user can interact
with to create the second request, which actually performs the desired
action (creating, editing, or deleting data). This is a very common in
teraction on the Web, and you’ll see several examples of it throughout
this book.
Unfortunately, we have not yet reached the point in the book where we are able to use Entity Framework, so for now you can choose the “MVC controller with empty read/ write actions” option and click Add to have Visual Studio generate the next controller class.
After Visual Studio is done creating the AuctionsController, find the Details action and update it so it creates a new instance of the Auction model shown earlier and passes that instance to the view using the View(object model) method.
Yes, this is a silly example. Normally, you’d retrieve this information from somewhere such as a database—and we will show you how to do just that in Chapter 4—but for this example, we are using hardcoded values:
public ActionResult Details(long id = 0)
{
var auction = new Ebuy.Website.Models.Auction {
Id = id,
Title = "Brand new Widget 2.0",
Description = "This is a brand new version 2.0 Widget!", StartPrice = 1.00m,
CurrentPrice = 13.40m,
StartTime = DateTime.Parse("6-15-2012 12:34 PM"),
EndTime = DateTime.Parse("6-23-2012 12:34 PM"),
};
Putting It All Together | 37
return View(auction);
}
The View
With a Details controller action in place and providing data to a view, it’s time to create that view.
As with the controller class in the previous section, you are free to manually add new views (and folders to store them in) directly to the Views folder; however, if you’re the type who prefers a bit more automation, Visual Studio offers yet another wizard to do the work of creating the views—and the folders they live in—for you.
To add a view using the Visual Studio wizard, simply right-click anywhere within the code of the action in a controller and choose the Add View option, which will display the Add View wizard (Figure 1-9). This is actually quite similar to the Add Controller dialog you just used to generate the AuctionsController.
Figure 1-9. Adding a view to an ASP.NET MVC application
The Add View dialog starts off by asking what you’d like to call the new view, defaulting to the name of the controller action from which you triggered the dialog (e.g., Details when called from the Details action). Then, the dialog allows you to choose the syntax
38 | Chapter 1: Fundamentals of ASP.NET MVC
(aka “View Engine”) that you’d like to use when authoring the view. This value defaults to the syntax you chose when you created the web project, but (as promised earlier) you are free to switch between syntaxes if it suits you, perhaps using Razor for some views and the “ASPX” Web Forms syntax for others.
As in the Add Controller dialog, the rest of the options in the Add View wizard have to do with the code and markup that Visual Studio is going to generate when it creates the new view. For example, you can choose to have a strongly typed view model (as discussed in “Strongly typed views” on page 33) by selecting the model type from the list of classes in your project, or typing the type name in yourself. If you choose a strongly typed view, the wizard also lets you choose a template (e.g., Edit, Create, Delete), which analyzes the model type and generates the appropriate form fields for that type.
This is a great way to get up and running quickly and can save you quite a bit of typing, so let’s take advantage of it by checking the “Create a strongly typed view” checkbox, choosing our Auction model from the “Model class” drop-down list, and selecting the Details scaffold template.
Visual Studio will only include in the “Model class” drop-down classes
that it has been able to compile successfully, so if you do not see the
Auction class you created earlier, try to compile the solution and then
open the Add View dialog again.
Finally, you’ll need to tell Visual Studio whether this view is a partial view or should refer to a layout. When you’re using the ASPX Web Forms syntax to author your pages and you choose the “Create as a partial view” option, Visual Studio will create it as a User Control (.ascx) rather than a full page (.aspx). When using the Razor syntax, however, the “Create as a partial view” option has very little effect—Visual Studio creates the same type of file (.cshtml or .vbhtml) for both partial views and full pages. In the case of Razor syntax, the only effect this checkbox has is on the markup that gets generated inside of the new view.
For the purposes of this demo, you can leave the defaults alone: “Create as a partial view” should remain unchecked, while “Use a layout or master page” should be checked, with the layout text box left empty (see Figure 1-10).
Putting It All Together | 39
Figure 1-10. Customizing your view
When you’re ready, click the Add button to have Visual Studio add the new view to your project. After it’s finished, you will see that Visual Studio has analyzed the Auc tion model and generated the required HTML markup—complete with references to HTML helpers such as Html.DisplayFor—to display all of the Auction fields.
At this point, you should be able to run your site, navigate to the controller action (e.g., /auctions/details/1234), and see the details of the Auction object rendered in your browser, as shown in Figure 1-11.
It sure isn’t pretty, but remember, the HTML that Visual Studio generates is just a starting point to help you save time. Once it’s generated, you can feel free to change it however you like.
Congratulations—you have just created your first controller action and view from scratch!
40 | Chapter 1: Fundamentals of ASP.NET MVC
Figure 1-11. The new view rendered in a browser
Authentication
So far we’ve covered just about everything you need to know in order to create an ASP.NET MVC application, but there is one more very important concept that you should know about before you continue with the rest of the book: how to protect your site by requiring users to authenticate themselves before they can access certain con troller actions.
You may have noticed that the Internet Application template generates an AccountCon troller—along with some views to support it—which provides a full implementation of forms authentication right out of the box. This is an acknowledgment that security and authentication are crucial to just about every web application and that, at some point, you’ll probably want to lock down some or all of your site to restrict access to specific users (or groups of users) and prevent unauthorized access by all other visitors. So, since you’ll most likely need it anyway, why shouldn’t Visual Studio generate the controller and views to get you started?
Authentication | 41
The traditional tactic used to lock down ASP.NET applications is to apply authorization settings to specific pages or directories via web.config configuration settings. Unfortu nately, this approach does not work in ASP.NET MVC applications because ASP.NET MVC applications rely on routing to controller actions, not to physical pages.
Instead, the ASP.NET MVC Framework provides the AuthorizeAttribute, which can be applied to individual controller actions—or even entire controllers—to restrict ac cess only to authenticated users or, alternatively, to specific users and user roles.
Take a look at the Profile action on the UsersController that we’ll create later in the book, which displays the profile information for the current user:
public class UsersController
{
public ActionResult Profile()
{
var user = _repository.GetUserByUsername(User.Identity.Name); return View("Profile", user);
}
}
Clearly, this action will fail if the user is not logged in. Applying the AuthorizeAttri bute to this controller action causes any requests made to this action by users who are not authenticated to be rejected:
public class UsersController
{
[Authorize]
public ActionResult Profile()
{
var user = _repository.GetUserByUsername(User.Identity.Name); return View("Profile", user);
}
}
If you’d like to be even more specific about the users who can access the controller action, the AuthorizeAttribute exposes the Users property, which accepts a comma delimited whitelist of acceptable usernames, as well as the Roles property, which accepts a list of allowed roles.
Now, when nonauthenticated users attempt to access this URL, they will instead be redirected to the login URL: the Login action on the AccountController.
The AccountController
In order to help you get a jump-start on your application, the ASP.NET MVC Internet Application project template includes the AccountController, which contains control ler actions that leverage the ASP.NET Membership Providers.
The AccountController provides quite a bit of functionality out of the box, along with the views to support each controller action. This means that your brand new ASP.NET
42 | Chapter 1: Fundamentals of ASP.NET MVC
MVC application already contains the following fully implemented features, without any coding on your part:
• Login
• Logoff
• New user registration
• Change password
Thus, when you apply the AuthorizeAttribute to any of your controller actions, users are redirected to the existing login page that the project template creates for you (see Figure 1-12).
Figure 1-12. The default login page
And, when users need to create a new account in order to log in, they can click the Register link to view the prebuilt Registration page (Figure 1-13).
Plus, if you don’t like the out-of-the-box views, they are easily customizable to meet your needs.
As this section shows, not only does the ASP.NET MVC Framework make it very easy to protect controller actions, but the default project template implements just about everything users will need to authenticate themselves on your site!
Authentication | 43
Figure 1-13. The default registration page
Summary
ASP.NET MVC leverages the time-tested Model-View-Controller architecture pattern to provide a website development framework that encourages loosely coupled archi tecture and many other popular object-oriented programming patterns and practices.
The ASP.NET MVC Framework gets you on the ground running right from the start with helpful project templates and a “convention over configuration” approach that cuts down on the amount of configuration required to create and maintain your ap plication, freeing up more of your time so you can be more productive in getting your application completed and out the door.
This chapter introduced you to the fundamental concepts and basic skills that you need in order to get up and running building ASP.NET MVC 4 applications. The rest of this book will expand on this foundation, showing more features that the ASP.NET MVC Framework has to offer to help you build robust, maintainable web applications using the MVC architectural pattern.
So, what are you waiting for? Keep reading and learn everything you need to know to build the greatest web applications you’ve ever written!
44 | Chapter 1: Fundamentals of ASP.NET MVC
CHAPTER 2
ASP.NET MVC for Web Forms
Developers
Even though their architectural approaches are quite different, ASP.NET MVC and Web Forms actually have a lot in common. After all, they are both built on top of the core ASP.NET APIs and the .NET Framework. So, if you are a Web Forms developer looking to learn the ASP.NET MVC Framework, you’re already further ahead than you may think!
In this chapter, we’ll compare and contrast the ASP.NET MVC and Web Forms Frame works to show how many of the concepts you use to build Web Forms applications relate to the ASP.NET MVC way of doing things. Note that this chapter is geared toward helping developers who are very familiar with the Web Forms Framework and want to translate that knowledge over to ASP.NET MVC to get up and running more quickly. If you are not very familiar with the Web Forms Framework, you may consider skipping this chapter and moving along to the rest of the book.
It’s All Just ASP.NET
You may not have known it, but the framework you’ve been using to develop web pages using the .NET Framework—what you probably call “ASP.NET"—can actually be broken down into two parts: the visual user interface components (aka “Web Forms”) and the nonvisual “backend” web components (aka “ASP.NET”). The two parts are most easily broken down by their .NET namespaces: everything under the System.Web.UI.* namespaces can be considered “Web Forms” and the rest of the Sys tem.Web.* namespaces can be considered “ASP.NET.”
Like Web Forms, ASP.NET MVC (whose classes fall under the System.Web.Mvc.* namespace) is built on top of the strong shoulders of the ASP.NET platform. As such, the two frameworks can be both very similar and incredibly different, depending on how you look at them. This section examines the similarities between the two frame works, while the rest of the chapter continues on to expose their numerous differences.
45
Tools, Languages, and APIs
For starters, both frameworks have access to the full extent of the .NET Framework and everything it has to offer. Naturally, both frameworks rely on the .NET languages of C# and Visual Basic .NET to interact with the .NET Framework, and can access compiled assemblies developed with any other language that the .NET Framework supports.
As a nice side effect, this feature makes your existing ASP.NET code highly reusable. For instance, if you have an existing Web Forms application that accesses data stored in XML files via the System.Xml API, you’ll most likely be able to reuse this code in an ASP.NET MVC application with little or no modification.
It should also come as no surprise that you’ll use Visual Studio to edit ASP.NET MVC websites and the projects they depend on, just like working with Web Forms applica tions (or any other .NET-based applications). You may even notice a few common artifacts, such as web.config and Global.asax, both of which play a large role in both ASP.NET MVC and Web Forms applications.
HTTP Handlers and Modules
Perhaps the most notable parts of the .NET Framework that ASP.NET MVC and Web Forms share are HTTP handlers and HTTP modules. And, even though most classes in the Web Forms API (the System.Web.UI namespace) simply won’t work in an ASP.NET MVC application, HTTP handlers and modules are actually part of the core ASP.NET (System.Web) API, so they are still quite functional in the context of an ASP.NET MVC application. In fact, the ASP.NET MVC pipeline itself starts out by handling incoming requests with an HTTP handler!
Be sure to read about all of the differences between the ASP.NET MVC
and Web Forms Frameworks in this chapter and consider how they
apply to HTTP handlers and modules. Though HTTP handlers and
modules themselves function just fine in an ASP.NET MVC application,
keep in mind that there are certain aspects—such as View State—that
will not work as expected.
Managing State
Managing state—the data related to a user—is an important part of any application, and the stateless nature of the Web makes this a particularly complex task within web applications.
To help deal with state management, ASP.NET Web Forms uses the View State mech anism, wherein state data for a request is serialized and stored in a hidden form field that gets posted back to the server with every subsequent request. View State is such a critical part of the Web Forms platform that nearly every page and component in the
46 | Chapter 2: ASP.NET MVC for Web Forms Developers
framework relies on it at some point. The View State abstraction also has its detriments, though, not the least of which is the fact that every request that contains View State must be a form post and that the potential size of the data in this field—data that is often not even necessary—can become quite large if it is not properly used.
As “State Management” on page 49 explains, ASP.NET MVC’s approach to state management is dramatically different, and in most cases, it leaves state management up to the developer to implement (or not). Most importantly, however, ASP.NET MVC deserts View State completely.
Luckily, the ASP.NET platform offers several state management techniques in addition to View State that continue to work in exactly the same way in ASP.NET MVC. Feel free to use the ASP.NET cache and session state, or even the HttpContext.Items APIs, just as you always have to help manage state in ASP.NET MVC applications.
Deployment and Runtime
ASP.NET MVC websites get deployed to the same kind of production environment as Web Forms applications. This means that just about everything you’ve already learned about deploying and maintaining an ASP.NET application—e.g., to do with Internet Information Server (IIS), .NET application pools, tracing, troubleshooting, and even deploying assemblies’ bin folders—continues to be quite relevant to deploying and maintaining ASP.NET MVC applications. Though ASP.NET MVC and Web Forms applications follow quite different architectures, in the end it’s all .NET code that gets deployed and executed to process HTTP requests.
More Differences than Similarities
The number of similarities that the previous section pointed out may have you thinking that ASP.NET MVC and Web Forms seem almost like the same framework. As you analyze the two frameworks more deeply, however, it becomes quite clear that they are much more different than their numerous similarities make them seem.
Table 2-1 illustrates this fact, comparing and contrasting a number of the frameworks’ core components.
Table 2-1. Fundamental differences between ASP.NET MVC and Web Forms Web Forms ASP.NET MVC
Views tightly coupled to logic View and logic kept very separate
Pages (file-based URLs) Controllers (route-based URLs)
State management (View State) No automatic state management
Web Forms syntax Customizable syntax (Razor as default)
Server controls HTML helpers
More Differences than Similarities | 47
Web Forms ASP.NET MVC
Master pages Layouts
User controls Partial views
Please note that—especially since both frameworks are built on top of
the ASP.NET platform—in many ways it is quite possible to make Web
Forms behave more like ASP.NET MVC, and vice versa. That is to say,
you are certainly able to apply many MVC techniques to Web Forms
applications, and vice versa.
However, keep in mind that the comparisons made throughout this
chapter refer to the standard development practices for each framework,
i.e., the way you see things done in “official” channels such as the API
documentation and tutorials.
Separation of Application Logic and View Logic
The most important difference between ASP.NET MVC and Web Forms is the funda mental architectural concepts they each employ.
For instance, Web Forms was introduced (ironically enough) to provide a better sep aration of concerns than its predecessor, the ASP Framework, which effectively forced developers to combine their business logic and markup in one single file. Web Forms not only gave developers the ability to separate their business logic from their markup, it also provided a much more powerful development platform—the .NET Frame work—in which to write the code that drove that business logic. But despite all of the advantages that Web Forms provided over traditional ASP scripts, the Web Forms architecture is still very much focused on “the page”; though the code is moved to another location, it is still quite difficult to truly separate the business logic that handles a request from the view that the user sees.
ASP.NET MVC, on the other hand, is built from the ground up on the concept of separation of concerns driven by loosely coupled components that work together to process a request. This approach not only benefits the development lifecycle by in creasing the ability to develop individual components in relative isolation, as well as the ability to test those components, but it also provides the ability to handle requests much more dynamically, as the next section demonstrates.
URLs and Routing
Under the Web Forms architecture, every one of a website’s external URLs is repre sented by a physical .aspx page, and each of those pages is tightly coupled to a single optional class (aka “code-behind”) that contains the logic for the page. Pages cannot dynamically choose the class they are bound to, and code-behind classes cannot render alternate views.
48 | Chapter 2: ASP.NET MVC for Web Forms Developers
The Web Forms page-based approach stands in stark contrast to the way that ASP.NET MVC handles requests, relying instead on potentially complex routing rules to dynam ically map external URLs to the appropriate controller actions and allowing the con troller action logic to dictate which view will be displayed to the user.
For instance, the pipeline may respond differently to a user navigating to the URL / auctions/details/123 in her browser than it responds to an AJAX request to that same URL, simply based on the fact that the AJAX request contains a special header that identifies it as an AJAX request. In the case of the user navigating directly to the URL, the server may return a full web page complete with HTML, JavaScript, and CSS, whereas the server may respond to the AJAX request with only the serialized data for the requested Auction and nothing more. What’s more, the server may even choose to serialize the Auction data in different formats—e.g., JSON or XML—based on aspects of the request such as the value of a query string parameter.
This kind of dynamic processing is simply not something that the Web Forms Frame work easily supports without resorting to the use of HTTP modules or HTTP handlers.
ASP.NET’s routing functionality is not limited to ASP.NET MVC ap
plications—it can also be used to customize the URLs in a Web Forms
application.
The primary difference between the two uses is that routing is such a
critical component in the ASAP.NET MVC architecture that the frame
work could not operate without it, whereas Web Forms applications
primarily use routing to avoid page file path restrictions and to gain
better control over their URLs.
State Management
Perhaps the most controversial difference between Web Forms and ASP.NET MVC is how they each handle the user’s state across requests—specifically, ASP.NET MVC ditches View State. How can something so fundamental be completely removed? The short answer is that ASP.NET MVC embraces the stateless nature of the Web. However, to gain a better idea of what this really means, let’s revisit the history of Web Forms one more time.
In addition to providing a better development platform than ASP, one of the original goals for the Web Forms Framework was to bring “thick,” native client application development techniques—such as “drag and drop” and other Rapid Application Development (RAD) concepts—to the Web.
In order to bring the Web and native client development experiences closer together, Web Forms had to create a layer of abstraction on top of fundamental web development concepts such as HTML markup and styling. One of the most significant concepts in native application development is that a native application is stateful, which means that
More Differences than Similarities | 49
the application is aware of the state of its interaction with the user and can even persist that state in order to reuse it across instances of the application.
The Web, on the other hand, is based on HTTP requests, with each request involving a single client request and a single server response. A web server must handle every HTTP request in isolation, unaware of any previous or future messages that may be exchanged with a given client—in effect, preventing the server and the client from having an on-going conversation in which the server is able to remember its previous interactions with the client.
In order to apply stateful interactions across a stateless medium, an abstraction must be applied—thus View State was born. Simply put, View State serializes the state of the interaction between the client and the server and stores that information in a hidden form field on every page that the server sends to the client. It’s then the client’s re sponsibility to pass along this serialized state on every subsequent request in the conversation.
Rather than attempt to duplicate this abstraction, ASP.NET MVC embraces the state less nature of the Web and provides no out-of-the-box alternative to View State other than server-side techniques such as caching and session state. Instead, ASP.NET MVC expects requests to include all the data that the server needs in order to process them. For instance, rather than retrieving an Auction from the database and serializing the whole object down to the client so the client can send the Auction object back during subsequent requests, ASP.NET MVC responses might reply with simply the Auction’s ID. Then, subsequent requests will include just the Auction’s ID, which the ASP.NET MVC controller processing the request uses to retrieve the Auction from the database for each request.
Clearly, both approaches have their benefits and trade-offs. Whereas View State makes many ongoing client interactions much simpler, the data contained within it can quickly and easily become unwieldy, using up a significant amount of bandwidth for data that may never be used. In other words, View State is meant to make developers’ lives easier without their having to think about it, but it comes at the cost of increased bandwidth, particularly when developers do not stop to consider what data their pages are storing.
ASP.NET MVC’s approach, on the other hand, may decrease page sizes, but at the cost of increased backend processing and (perhaps) database requests in order to fully re hydrate the request’s state on the server.
Rendering HTML
Every website is different, but one thing all websites have in common is that their need to generate HTML. One of the primary requirements for any web application frame work is the ability to help developers render that HTML as productively as possible. Both ASP.NET MVC and Web Forms do this very well—but they do so in drastically different ways.
50 | Chapter 2: ASP.NET MVC for Web Forms Developers
Web Forms views are easily distinguishable at a glance; just about everything in Web Forms views—from
@bid.Username
@bid.Amount
}
Last Bid Amount: @bid.Amount
}
@section Footer {
Copyright @DateTime.Now.Year
}
This is the main content.
Razor layouts and the content views that depend on them are assembled together like puzzle pieces, each one defining one or more portions of the entire page. When all the pieces get assembled, the result is a complete web page.
Views | 29
Partial Views
While layouts offer a helpful way to reuse portions of markup and maintain a consistent look and feel throughout multiple pages in your site, some scenarios may require a more focused approach.
The most common scenario is needing to display the same high-level information in multiple locations in a site, but only on a few specific pages and in different places on each of those pages.
For instance, the Ebuy auction site may render a list of compact auction details— showing only the auction’s title, current price, and perhaps a thumbnail of the item— in multiple places in the site such as the search results page as well as a list of featured auctions on the site’s homepage.
ASP.NET MVC supports these kinds of scenarios through partial views.
Partial views are views that contain targeted markup designed to be rendered as part of a larger view. The following snippet demonstrates a partial view to display the com pact auction details mentioned in the scenario above:
@model Auction
To render this snippet as a partial view, simply save it as its own standalone view file (e.g. /Views/Shared/Auction.cshtml) and use one of ASP.NET MVC’s HTML Helpers —Html.Partial()—to render the view as part of another view.
To see this in action, take a look at the following snippet, which iterates over a collection of auction objects and uses the partial view above to render the HTML for each auction:
@model IEnumerable
Search Results
@foreach(var auction in Model) {
@Html.Partial("Auction", auction)
}
Notice that the first parameter to the Html.Partial() helper method is a string con taining the name of the view without its extension.
This is because the Html.Partial() helper method is just a simple layer on top of ASP.NET MVC’s powerful view engine, which renders the view very similar to what occurs after a controller action calls the View() method to return a view action result: the engine uses the view name to locate and execute the appropriate view.
30 | Chapter 1: Fundamentals of ASP.NET MVC
In this way, partial views are developed and executed almost exactly like any other kind of view. The only difference is that they are designed to be rendered as part of a larger view.
The second parameter (auction in the example above) accepts the partial view’s model, just like the model parameter in the View(_View Name_, _[Model]_) controller helper method. This second model parameter is optional; when it’s not specified, it defaults to the model in the view from which the Html.Partial() helper was called. For instance, if the second auction parameter were omitted in the example above, ASP.NET MVC would pass the view’s Model property (of type IEnumerable) in its place.
The examples above show how partial views can provide reusable sec
tions of markup that can help reduce duplication and complexity in your
views.
Though useful, this is only one way to take advantage of partial views—
“Partial Rendering” on page 111 shows how to take advantage of partial
views to provide a simple and effective way to enhance your site with
AJAX.
Displaying Data
The MVC architecture depends on the model, view, and controller all remaining sep arate and distinct, while still working together to accomplish a common goal. In this relationship, it is the controller’s job to be the “traffic cop,” coordinating various parts of the system to execute the application’s logic. This processing typically results in some kind of data that needs to be relayed to the user. Alas, it is not the controller’s job to display things to the user—that is what views are for! The question then becomes, how does the controller communicate this information to the view?
ASP.NET MVC offers two ways to communicate data across model-view-controller boundaries: ViewData and TempData. These objects are dictionaries available as proper ties in both controllers and views. Thus, passing data from a controller to a view can be as simple as setting a value in the controller, as in this snippet from HomeController.cs:
public ActionResult About()
{
ViewData["Username"] = User.Identity.Username;
ViewData["CompanyName"] = "EBuy: The ASP.NET MVC Demo Site";
ViewData["CompanyDescription"] =
"EBuy is the world leader in ASP.NET MVC demoing!";
return View("About");
}
and referencing the value in the view, as in this portion of the About.cshtml file: Views | 31
@ViewData["CompanyName"]
@ViewData["CompanyDescription"]
Cleaner access to ViewData values via ViewBag
ASP.NET MVC controllers and views that expose the ViewData property also expose a similar property named ViewBag. The ViewBag property is simply a wrapper around the ViewData that exposes the ViewData dictionary as a dynamic object.
For example, any references to values in the ViewData dictionary in the preceding snip pets can be replaced with references to dynamic properties on the ViewBag object, as in:
public ActionResult About()
{
ViewBag.Username = User.Identity.Username;
ViewBag.CompanyName = "EBuy: The ASP.NET MVC Demo Site";
ViewBag.CompanyDescription = "EBuy is the world leader in ASP.NET MVC demoing!";
return View("About");
}
and:
@ViewBag.CompanyName
@ViewBag.CompanyDescription
View models
In addition to its basic dictionary behavior, the ViewData object also offers a Model property, which represents the primary object that is the target of the request. Though the ViewData.Model property is conceptually no different from ViewData["Model"], it promotes the model to a first-class citizen and recognizes it as more important than the other data that might be in the request.
For example, the previous two snippets showed that the CompanyName and CompanyDe scription dictionary values are clearly related to each other and represent a great opportunity to wrap together in a model.
Take a look at CompanyInfo.cs:
public class CompanyInfo
{
public string Name { get; set; }
public string Description { get; set; }
}
the About action in HomeController.cs:
public ActionResult About()
{
ViewBag.Username = User.Identity.Username;
var company = new CompanyInfo {
Name = "EBuy: The ASP.NET MVC Demo Site",
32 | Chapter 1: Fundamentals of ASP.NET MVC
Description = "EBuy is the world leader in ASP.NET MVC demoing!", };
return View("About", company);
}
and this snippet from About.cshtml:
@{ var company = (CompanyInfo)ViewData.Model; }
@company.Name
@company.Description
In these snippets, the references to the CompanyName and CompanyDescription dictionary values have been merged into an instance of a new class named CompanyInfo (com pany). The updated HomeController.cs snippet also shows an overload of the View() helper method in action. This overload continues to accept the name of the desired view as the first parameter. The second parameter, however, represents the object that will be assigned to the ViewData.Model property.
Now, instead of setting the dictionary values directly, company is passed as the model parameter to the View() helper method and the view (About.cshtml) can get a local reference to the company object and access its values.
Strongly typed views
By default, the Model property available within Razor views is dynamic, which means that you are able to access its values without needing to know its exact type.
However, given the static nature of the C# language and Visual Studio’s excellent In telliSense support for Razor views, it is often beneficial to specify the type of the page’s model explicitly.
Luckily, Razor makes this pretty easy—simply use the @model keyword to indicate the model’s type name:
@model Auction
@Model.Name
@Model.Description
This example modifies the previous Auction.cshtml example, avoiding the need to add an intermediary variable to cast the ViewData.Model into. Instead, the first line uses the @model keyword to indicate that the model’s type is CompanyInfo, making all references to ViewData.Model strongly typed and directly accessible.
HTML and URL Helpers
The primary goal of most web requests is to deliver HTML to the user, and as such, ASP.NET MVC goes out of its way to help you create HTML. In addition to the Razor markup language, ASP.NET MVC also offers many helpers to generate HTML simply
Views | 33
and effectively. The two most important of these helpers are the HtmlHelper and Url Helper classes, exposed in controllers and views as the Html and Url properties, respectively.
Here are some examples of the two helpers in action:
@Html.ActionLink("Homepage", "Index", "Home")
The rendered markup looks like this:
Homepage
For the most part, the HtmlHelper and UrlHelper types don’t have many methods of their own and are merely shims that the framework attaches behaviors to via extension methods. This makes them an important extensibility point, and you’ll see references to the two types throughout this book.
Though there are far too many methods to list in this section, the one thing to take away at this point is: the HtmlHelper class helps you generate HTML markup and the UrlHelper class helps you generate URLs. Keep this in mind, and turn to these helpers anytime you need to generate URLs or HTML.
Models
Now that we’ve covered controllers and views, it’s time to complete the definition of MVC by discussing models, which are usually considered the most important part of the MVC architecture. If they are so important, why are they the last to be explained? Well, the model layer is notoriously difficult to explain because it is the layer that contains all of the business logic for the application—and that logic is different for every application.
From a more technical standpoint, the model typically consists of normal classes that expose data in the form of properties and logic in the form of methods. These classes come in all shapes and sizes, but the most common example is the “data model” or “domain model,” whose primary job is to manage data.
For example, take a look at the following snippet, which shows the Auction class—the model that will drive the entire EBuy reference application:
public class Auction
{
public long Id { get; set; }
public string Title { get; set; }
public string Description { get; set; }
public decimal StartPrice { get; set; }
public decimal CurrentPrice { get; set; }
public DateTime StartTime { get; set; }
public DateTime EndTime { get; set; }
}
34 | Chapter 1: Fundamentals of ASP.NET MVC
Though we will add various functionality such as validation and behavior to the Auc tion class throughout this book, this snippet is still very representative of a model in that it defines the data that makes up an “auction.”
And, just as we will build on the Auction class throughout the book, be on the lookout for more kinds of classes (such as services and helpers) that all work together to make up the “Model” in “MVC.”
Putting It All Together
So far we’ve described all the parts that make up an ASP.NET MVC application, but the discussion has focused on the code that Visual Studio generates for us as part of the project template. In other words, we haven’t actually made anything yet. So let’s change that!
This section will focus on how to implement a feature from scratch, creating everything you need to accomplish an example scenario: displaying an auction. As a recap, every ASP.NET MVC request requires at least three things: a route, a controller action, and a view (and, optionally, a model).
The Route
To figure out the routing pattern that you’d like to use for a given feature, you must first determine what you’d like your URL for that feature to look like. In this example we are going to choose a relatively standard URL of Auctions/Details/[Auction ID]; for example, http://www.ebuy.biz/Auctions/Details/1234.
What a nice surprise—the default route configuration already supports this URL!
The Controller
Next, we’ll need to create a controller to host the actions that will process the request.
Since controllers are merely classes that implement the ASP.NET MVC controller interface, you could manually add a new class to the Controllers folder that derives from System.Web.Mvc.Controller and begin adding controller actions to that class. However, Visual Studio offers a bit of tooling to take most of the work out of creating new controllers: simply right-click on the Controllers folder and choose the Add > Con troller... menu option, which will pop up the Add Controller dialog shown in Figure 1-8.
Putting It All Together | 35
Figure 1-8. Adding a controller to an ASP.NET MVC application
The Add Controller dialog begins by asking for the name of the new controller class (in this case, we’ll call it AuctionsController) and follows up by asking which scaffold ing template you’d like to use, along with providing a set of options to give you a little bit of control over how ASP.NET MVC is going to generate the new controller class.
Controller templates
The Add Controller dialog offers several different controller templates that can help you get started developing your controllers more quickly:
Empty MVC controller
The default template (“Empty MVC controller”) is the simplest one. It doesn’t offer any customization options because, well, it’s too simple to have any options! It merely creates a new controller with the given name that has a single generated action named Index.
MVC controller with read/write actions and views, using Entity Framework The “MVC controller with read/write actions and views, using Entity Framework” template is just as impressive as it sounds. This template starts with the same output as the “MVC controller with empty read/write actions” template (see below) and then kicks it up a notch, generating code to help you access objects stored in an Entity Framework context and even generating Create, Edit, Details, and Delete views for those objects! This template is a great kick-start when your project uses Entity Framework to access your data, and in some cases the code it generates may be all that you need to support the Read, Edit, Update, and Delete operations for that data.
36 | Chapter 1: Fundamentals of ASP.NET MVC
MVC controller with empty read/write actions
The next option—“MVC controller with empty read/write actions”—generates the same code as the “Empty MVC controller” template, but adds a few more actions that you’ll most likely need in order to expose standard “data access” op erations: Details, Create, Edit, and Delete.
API controller templates
The final three templates—“Empty API controller,” “API controller with empty read/write actions,” and “API controller with read/write actions and views, using Entity Framework”—are the Web API counterparts to the MVC controller tem plates of the same names. We will cover these templates in more detail when we discuss ASP.NET MVC’s Web API functionality in Chapter 6.
An interesting thing to notice about the controller code that Visual Stu
dio generates is that the Index and Details actions each have only one
method, while the Create, Edit, and Delete actions each have two over
loads—one decorated with an HttpPost Attribute, and one without.
This is because Create, Edit, and Delete all involve two requests in order
to complete: the first request returns the view that the user can interact
with to create the second request, which actually performs the desired
action (creating, editing, or deleting data). This is a very common in
teraction on the Web, and you’ll see several examples of it throughout
this book.
Unfortunately, we have not yet reached the point in the book where we are able to use Entity Framework, so for now you can choose the “MVC controller with empty read/ write actions” option and click Add to have Visual Studio generate the next controller class.
After Visual Studio is done creating the AuctionsController, find the Details action and update it so it creates a new instance of the Auction model shown earlier and passes that instance to the view using the View(object model) method.
Yes, this is a silly example. Normally, you’d retrieve this information from somewhere such as a database—and we will show you how to do just that in Chapter 4—but for this example, we are using hardcoded values:
public ActionResult Details(long id = 0)
{
var auction = new Ebuy.Website.Models.Auction {
Id = id,
Title = "Brand new Widget 2.0",
Description = "This is a brand new version 2.0 Widget!", StartPrice = 1.00m,
CurrentPrice = 13.40m,
StartTime = DateTime.Parse("6-15-2012 12:34 PM"),
EndTime = DateTime.Parse("6-23-2012 12:34 PM"),
};
Putting It All Together | 37
return View(auction);
}
The View
With a Details controller action in place and providing data to a view, it’s time to create that view.
As with the controller class in the previous section, you are free to manually add new views (and folders to store them in) directly to the Views folder; however, if you’re the type who prefers a bit more automation, Visual Studio offers yet another wizard to do the work of creating the views—and the folders they live in—for you.
To add a view using the Visual Studio wizard, simply right-click anywhere within the code of the action in a controller and choose the Add View option, which will display the Add View wizard (Figure 1-9). This is actually quite similar to the Add Controller dialog you just used to generate the AuctionsController.
Figure 1-9. Adding a view to an ASP.NET MVC application
The Add View dialog starts off by asking what you’d like to call the new view, defaulting to the name of the controller action from which you triggered the dialog (e.g., Details when called from the Details action). Then, the dialog allows you to choose the syntax
38 | Chapter 1: Fundamentals of ASP.NET MVC
(aka “View Engine”) that you’d like to use when authoring the view. This value defaults to the syntax you chose when you created the web project, but (as promised earlier) you are free to switch between syntaxes if it suits you, perhaps using Razor for some views and the “ASPX” Web Forms syntax for others.
As in the Add Controller dialog, the rest of the options in the Add View wizard have to do with the code and markup that Visual Studio is going to generate when it creates the new view. For example, you can choose to have a strongly typed view model (as discussed in “Strongly typed views” on page 33) by selecting the model type from the list of classes in your project, or typing the type name in yourself. If you choose a strongly typed view, the wizard also lets you choose a template (e.g., Edit, Create, Delete), which analyzes the model type and generates the appropriate form fields for that type.
This is a great way to get up and running quickly and can save you quite a bit of typing, so let’s take advantage of it by checking the “Create a strongly typed view” checkbox, choosing our Auction model from the “Model class” drop-down list, and selecting the Details scaffold template.
Visual Studio will only include in the “Model class” drop-down classes
that it has been able to compile successfully, so if you do not see the
Auction class you created earlier, try to compile the solution and then
open the Add View dialog again.
Finally, you’ll need to tell Visual Studio whether this view is a partial view or should refer to a layout. When you’re using the ASPX Web Forms syntax to author your pages and you choose the “Create as a partial view” option, Visual Studio will create it as a User Control (.ascx) rather than a full page (.aspx). When using the Razor syntax, however, the “Create as a partial view” option has very little effect—Visual Studio creates the same type of file (.cshtml or .vbhtml) for both partial views and full pages. In the case of Razor syntax, the only effect this checkbox has is on the markup that gets generated inside of the new view.
For the purposes of this demo, you can leave the defaults alone: “Create as a partial view” should remain unchecked, while “Use a layout or master page” should be checked, with the layout text box left empty (see Figure 1-10).
Putting It All Together | 39
Figure 1-10. Customizing your view
When you’re ready, click the Add button to have Visual Studio add the new view to your project. After it’s finished, you will see that Visual Studio has analyzed the Auc tion model and generated the required HTML markup—complete with references to HTML helpers such as Html.DisplayFor—to display all of the Auction fields.
At this point, you should be able to run your site, navigate to the controller action (e.g., /auctions/details/1234), and see the details of the Auction object rendered in your browser, as shown in Figure 1-11.
It sure isn’t pretty, but remember, the HTML that Visual Studio generates is just a starting point to help you save time. Once it’s generated, you can feel free to change it however you like.
Congratulations—you have just created your first controller action and view from scratch!
40 | Chapter 1: Fundamentals of ASP.NET MVC
Figure 1-11. The new view rendered in a browser
Authentication
So far we’ve covered just about everything you need to know in order to create an ASP.NET MVC application, but there is one more very important concept that you should know about before you continue with the rest of the book: how to protect your site by requiring users to authenticate themselves before they can access certain con troller actions.
You may have noticed that the Internet Application template generates an AccountCon troller—along with some views to support it—which provides a full implementation of forms authentication right out of the box. This is an acknowledgment that security and authentication are crucial to just about every web application and that, at some point, you’ll probably want to lock down some or all of your site to restrict access to specific users (or groups of users) and prevent unauthorized access by all other visitors. So, since you’ll most likely need it anyway, why shouldn’t Visual Studio generate the controller and views to get you started?
Authentication | 41
The traditional tactic used to lock down ASP.NET applications is to apply authorization settings to specific pages or directories via web.config configuration settings. Unfortu nately, this approach does not work in ASP.NET MVC applications because ASP.NET MVC applications rely on routing to controller actions, not to physical pages.
Instead, the ASP.NET MVC Framework provides the AuthorizeAttribute, which can be applied to individual controller actions—or even entire controllers—to restrict ac cess only to authenticated users or, alternatively, to specific users and user roles.
Take a look at the Profile action on the UsersController that we’ll create later in the book, which displays the profile information for the current user:
public class UsersController
{
public ActionResult Profile()
{
var user = _repository.GetUserByUsername(User.Identity.Name); return View("Profile", user);
}
}
Clearly, this action will fail if the user is not logged in. Applying the AuthorizeAttri bute to this controller action causes any requests made to this action by users who are not authenticated to be rejected:
public class UsersController
{
[Authorize]
public ActionResult Profile()
{
var user = _repository.GetUserByUsername(User.Identity.Name); return View("Profile", user);
}
}
If you’d like to be even more specific about the users who can access the controller action, the AuthorizeAttribute exposes the Users property, which accepts a comma delimited whitelist of acceptable usernames, as well as the Roles property, which accepts a list of allowed roles.
Now, when nonauthenticated users attempt to access this URL, they will instead be redirected to the login URL: the Login action on the AccountController.
The AccountController
In order to help you get a jump-start on your application, the ASP.NET MVC Internet Application project template includes the AccountController, which contains control ler actions that leverage the ASP.NET Membership Providers.
The AccountController provides quite a bit of functionality out of the box, along with the views to support each controller action. This means that your brand new ASP.NET
42 | Chapter 1: Fundamentals of ASP.NET MVC
MVC application already contains the following fully implemented features, without any coding on your part:
• Login
• Logoff
• New user registration
• Change password
Thus, when you apply the AuthorizeAttribute to any of your controller actions, users are redirected to the existing login page that the project template creates for you (see Figure 1-12).
Figure 1-12. The default login page
And, when users need to create a new account in order to log in, they can click the Register link to view the prebuilt Registration page (Figure 1-13).
Plus, if you don’t like the out-of-the-box views, they are easily customizable to meet your needs.
As this section shows, not only does the ASP.NET MVC Framework make it very easy to protect controller actions, but the default project template implements just about everything users will need to authenticate themselves on your site!
Authentication | 43
Figure 1-13. The default registration page
Summary
ASP.NET MVC leverages the time-tested Model-View-Controller architecture pattern to provide a website development framework that encourages loosely coupled archi tecture and many other popular object-oriented programming patterns and practices.
The ASP.NET MVC Framework gets you on the ground running right from the start with helpful project templates and a “convention over configuration” approach that cuts down on the amount of configuration required to create and maintain your ap plication, freeing up more of your time so you can be more productive in getting your application completed and out the door.
This chapter introduced you to the fundamental concepts and basic skills that you need in order to get up and running building ASP.NET MVC 4 applications. The rest of this book will expand on this foundation, showing more features that the ASP.NET MVC Framework has to offer to help you build robust, maintainable web applications using the MVC architectural pattern.
So, what are you waiting for? Keep reading and learn everything you need to know to build the greatest web applications you’ve ever written!
44 | Chapter 1: Fundamentals of ASP.NET MVC
CHAPTER 2
ASP.NET MVC for Web Forms
Developers
Even though their architectural approaches are quite different, ASP.NET MVC and Web Forms actually have a lot in common. After all, they are both built on top of the core ASP.NET APIs and the .NET Framework. So, if you are a Web Forms developer looking to learn the ASP.NET MVC Framework, you’re already further ahead than you may think!
In this chapter, we’ll compare and contrast the ASP.NET MVC and Web Forms Frame works to show how many of the concepts you use to build Web Forms applications relate to the ASP.NET MVC way of doing things. Note that this chapter is geared toward helping developers who are very familiar with the Web Forms Framework and want to translate that knowledge over to ASP.NET MVC to get up and running more quickly. If you are not very familiar with the Web Forms Framework, you may consider skipping this chapter and moving along to the rest of the book.
It’s All Just ASP.NET
You may not have known it, but the framework you’ve been using to develop web pages using the .NET Framework—what you probably call “ASP.NET"—can actually be broken down into two parts: the visual user interface components (aka “Web Forms”) and the nonvisual “backend” web components (aka “ASP.NET”). The two parts are most easily broken down by their .NET namespaces: everything under the System.Web.UI.* namespaces can be considered “Web Forms” and the rest of the Sys tem.Web.* namespaces can be considered “ASP.NET.”
Like Web Forms, ASP.NET MVC (whose classes fall under the System.Web.Mvc.* namespace) is built on top of the strong shoulders of the ASP.NET platform. As such, the two frameworks can be both very similar and incredibly different, depending on how you look at them. This section examines the similarities between the two frame works, while the rest of the chapter continues on to expose their numerous differences.
45
Tools, Languages, and APIs
For starters, both frameworks have access to the full extent of the .NET Framework and everything it has to offer. Naturally, both frameworks rely on the .NET languages of C# and Visual Basic .NET to interact with the .NET Framework, and can access compiled assemblies developed with any other language that the .NET Framework supports.
As a nice side effect, this feature makes your existing ASP.NET code highly reusable. For instance, if you have an existing Web Forms application that accesses data stored in XML files via the System.Xml API, you’ll most likely be able to reuse this code in an ASP.NET MVC application with little or no modification.
It should also come as no surprise that you’ll use Visual Studio to edit ASP.NET MVC websites and the projects they depend on, just like working with Web Forms applica tions (or any other .NET-based applications). You may even notice a few common artifacts, such as web.config and Global.asax, both of which play a large role in both ASP.NET MVC and Web Forms applications.
HTTP Handlers and Modules
Perhaps the most notable parts of the .NET Framework that ASP.NET MVC and Web Forms share are HTTP handlers and HTTP modules. And, even though most classes in the Web Forms API (the System.Web.UI namespace) simply won’t work in an ASP.NET MVC application, HTTP handlers and modules are actually part of the core ASP.NET (System.Web) API, so they are still quite functional in the context of an ASP.NET MVC application. In fact, the ASP.NET MVC pipeline itself starts out by handling incoming requests with an HTTP handler!
Be sure to read about all of the differences between the ASP.NET MVC
and Web Forms Frameworks in this chapter and consider how they
apply to HTTP handlers and modules. Though HTTP handlers and
modules themselves function just fine in an ASP.NET MVC application,
keep in mind that there are certain aspects—such as View State—that
will not work as expected.
Managing State
Managing state—the data related to a user—is an important part of any application, and the stateless nature of the Web makes this a particularly complex task within web applications.
To help deal with state management, ASP.NET Web Forms uses the View State mech anism, wherein state data for a request is serialized and stored in a hidden form field that gets posted back to the server with every subsequent request. View State is such a critical part of the Web Forms platform that nearly every page and component in the
46 | Chapter 2: ASP.NET MVC for Web Forms Developers
framework relies on it at some point. The View State abstraction also has its detriments, though, not the least of which is the fact that every request that contains View State must be a form post and that the potential size of the data in this field—data that is often not even necessary—can become quite large if it is not properly used.
As “State Management” on page 49 explains, ASP.NET MVC’s approach to state management is dramatically different, and in most cases, it leaves state management up to the developer to implement (or not). Most importantly, however, ASP.NET MVC deserts View State completely.
Luckily, the ASP.NET platform offers several state management techniques in addition to View State that continue to work in exactly the same way in ASP.NET MVC. Feel free to use the ASP.NET cache and session state, or even the HttpContext.Items APIs, just as you always have to help manage state in ASP.NET MVC applications.
Deployment and Runtime
ASP.NET MVC websites get deployed to the same kind of production environment as Web Forms applications. This means that just about everything you’ve already learned about deploying and maintaining an ASP.NET application—e.g., to do with Internet Information Server (IIS), .NET application pools, tracing, troubleshooting, and even deploying assemblies’ bin folders—continues to be quite relevant to deploying and maintaining ASP.NET MVC applications. Though ASP.NET MVC and Web Forms applications follow quite different architectures, in the end it’s all .NET code that gets deployed and executed to process HTTP requests.
More Differences than Similarities
The number of similarities that the previous section pointed out may have you thinking that ASP.NET MVC and Web Forms seem almost like the same framework. As you analyze the two frameworks more deeply, however, it becomes quite clear that they are much more different than their numerous similarities make them seem.
Table 2-1 illustrates this fact, comparing and contrasting a number of the frameworks’ core components.
Table 2-1. Fundamental differences between ASP.NET MVC and Web Forms Web Forms ASP.NET MVC
Views tightly coupled to logic View and logic kept very separate
Pages (file-based URLs) Controllers (route-based URLs)
State management (View State) No automatic state management
Web Forms syntax Customizable syntax (Razor as default)
Server controls HTML helpers
More Differences than Similarities | 47
Web Forms ASP.NET MVC
Master pages Layouts
User controls Partial views
Please note that—especially since both frameworks are built on top of
the ASP.NET platform—in many ways it is quite possible to make Web
Forms behave more like ASP.NET MVC, and vice versa. That is to say,
you are certainly able to apply many MVC techniques to Web Forms
applications, and vice versa.
However, keep in mind that the comparisons made throughout this
chapter refer to the standard development practices for each framework,
i.e., the way you see things done in “official” channels such as the API
documentation and tutorials.
Separation of Application Logic and View Logic
The most important difference between ASP.NET MVC and Web Forms is the funda mental architectural concepts they each employ.
For instance, Web Forms was introduced (ironically enough) to provide a better sep aration of concerns than its predecessor, the ASP Framework, which effectively forced developers to combine their business logic and markup in one single file. Web Forms not only gave developers the ability to separate their business logic from their markup, it also provided a much more powerful development platform—the .NET Frame work—in which to write the code that drove that business logic. But despite all of the advantages that Web Forms provided over traditional ASP scripts, the Web Forms architecture is still very much focused on “the page”; though the code is moved to another location, it is still quite difficult to truly separate the business logic that handles a request from the view that the user sees.
ASP.NET MVC, on the other hand, is built from the ground up on the concept of separation of concerns driven by loosely coupled components that work together to process a request. This approach not only benefits the development lifecycle by in creasing the ability to develop individual components in relative isolation, as well as the ability to test those components, but it also provides the ability to handle requests much more dynamically, as the next section demonstrates.
URLs and Routing
Under the Web Forms architecture, every one of a website’s external URLs is repre sented by a physical .aspx page, and each of those pages is tightly coupled to a single optional class (aka “code-behind”) that contains the logic for the page. Pages cannot dynamically choose the class they are bound to, and code-behind classes cannot render alternate views.
48 | Chapter 2: ASP.NET MVC for Web Forms Developers
The Web Forms page-based approach stands in stark contrast to the way that ASP.NET MVC handles requests, relying instead on potentially complex routing rules to dynam ically map external URLs to the appropriate controller actions and allowing the con troller action logic to dictate which view will be displayed to the user.
For instance, the pipeline may respond differently to a user navigating to the URL / auctions/details/123 in her browser than it responds to an AJAX request to that same URL, simply based on the fact that the AJAX request contains a special header that identifies it as an AJAX request. In the case of the user navigating directly to the URL, the server may return a full web page complete with HTML, JavaScript, and CSS, whereas the server may respond to the AJAX request with only the serialized data for the requested Auction and nothing more. What’s more, the server may even choose to serialize the Auction data in different formats—e.g., JSON or XML—based on aspects of the request such as the value of a query string parameter.
This kind of dynamic processing is simply not something that the Web Forms Frame work easily supports without resorting to the use of HTTP modules or HTTP handlers.
ASP.NET’s routing functionality is not limited to ASP.NET MVC ap
plications—it can also be used to customize the URLs in a Web Forms
application.
The primary difference between the two uses is that routing is such a
critical component in the ASAP.NET MVC architecture that the frame
work could not operate without it, whereas Web Forms applications
primarily use routing to avoid page file path restrictions and to gain
better control over their URLs.
State Management
Perhaps the most controversial difference between Web Forms and ASP.NET MVC is how they each handle the user’s state across requests—specifically, ASP.NET MVC ditches View State. How can something so fundamental be completely removed? The short answer is that ASP.NET MVC embraces the stateless nature of the Web. However, to gain a better idea of what this really means, let’s revisit the history of Web Forms one more time.
In addition to providing a better development platform than ASP, one of the original goals for the Web Forms Framework was to bring “thick,” native client application development techniques—such as “drag and drop” and other Rapid Application Development (RAD) concepts—to the Web.
In order to bring the Web and native client development experiences closer together, Web Forms had to create a layer of abstraction on top of fundamental web development concepts such as HTML markup and styling. One of the most significant concepts in native application development is that a native application is stateful, which means that
More Differences than Similarities | 49
the application is aware of the state of its interaction with the user and can even persist that state in order to reuse it across instances of the application.
The Web, on the other hand, is based on HTTP requests, with each request involving a single client request and a single server response. A web server must handle every HTTP request in isolation, unaware of any previous or future messages that may be exchanged with a given client—in effect, preventing the server and the client from having an on-going conversation in which the server is able to remember its previous interactions with the client.
In order to apply stateful interactions across a stateless medium, an abstraction must be applied—thus View State was born. Simply put, View State serializes the state of the interaction between the client and the server and stores that information in a hidden form field on every page that the server sends to the client. It’s then the client’s re sponsibility to pass along this serialized state on every subsequent request in the conversation.
Rather than attempt to duplicate this abstraction, ASP.NET MVC embraces the state less nature of the Web and provides no out-of-the-box alternative to View State other than server-side techniques such as caching and session state. Instead, ASP.NET MVC expects requests to include all the data that the server needs in order to process them. For instance, rather than retrieving an Auction from the database and serializing the whole object down to the client so the client can send the Auction object back during subsequent requests, ASP.NET MVC responses might reply with simply the Auction’s ID. Then, subsequent requests will include just the Auction’s ID, which the ASP.NET MVC controller processing the request uses to retrieve the Auction from the database for each request.
Clearly, both approaches have their benefits and trade-offs. Whereas View State makes many ongoing client interactions much simpler, the data contained within it can quickly and easily become unwieldy, using up a significant amount of bandwidth for data that may never be used. In other words, View State is meant to make developers’ lives easier without their having to think about it, but it comes at the cost of increased bandwidth, particularly when developers do not stop to consider what data their pages are storing.
ASP.NET MVC’s approach, on the other hand, may decrease page sizes, but at the cost of increased backend processing and (perhaps) database requests in order to fully re hydrate the request’s state on the server.
Rendering HTML
Every website is different, but one thing all websites have in common is that their need to generate HTML. One of the primary requirements for any web application frame work is the ability to help developers render that HTML as productively as possible. Both ASP.NET MVC and Web Forms do this very well—but they do so in drastically different ways.
50 | Chapter 2: ASP.NET MVC for Web Forms Developers
Web Forms views are easily distinguishable at a glance; just about everything in Web Forms views—from
Search Results
@foreach(var auction in Model) { @Html.Partial("Auction", auction) } Notice that the first parameter to the Html.Partial() helper method is a string con taining the name of the view without its extension. This is because the Html.Partial() helper method is just a simple layer on top of ASP.NET MVC’s powerful view engine, which renders the view very similar to what occurs after a controller action calls the View() method to return a view action result: the engine uses the view name to locate and execute the appropriate view. 30 | Chapter 1: Fundamentals of ASP.NET MVC In this way, partial views are developed and executed almost exactly like any other kind of view. The only difference is that they are designed to be rendered as part of a larger view. The second parameter (auction in the example above) accepts the partial view’s model, just like the model parameter in the View(_View Name_, _[Model]_) controller helper method. This second model parameter is optional; when it’s not specified, it defaults to the model in the view from which the Html.Partial() helper was called. For instance, if the second auction parameter were omitted in the example above, ASP.NET MVC would pass the view’s Model property (of type IEnumerable@ViewData["CompanyName"]
@ViewData["CompanyDescription"]
Cleaner access to ViewData values via ViewBag
ASP.NET MVC controllers and views that expose the ViewData property also expose a similar property named ViewBag. The ViewBag property is simply a wrapper around the ViewData that exposes the ViewData dictionary as a dynamic object.
For example, any references to values in the ViewData dictionary in the preceding snip pets can be replaced with references to dynamic properties on the ViewBag object, as in:
public ActionResult About()
{
ViewBag.Username = User.Identity.Username;
ViewBag.CompanyName = "EBuy: The ASP.NET MVC Demo Site";
ViewBag.CompanyDescription = "EBuy is the world leader in ASP.NET MVC demoing!";
return View("About");
}
and:
@ViewBag.CompanyName
@ViewBag.CompanyDescription
View models
In addition to its basic dictionary behavior, the ViewData object also offers a Model property, which represents the primary object that is the target of the request. Though the ViewData.Model property is conceptually no different from ViewData["Model"], it promotes the model to a first-class citizen and recognizes it as more important than the other data that might be in the request.
For example, the previous two snippets showed that the CompanyName and CompanyDe scription dictionary values are clearly related to each other and represent a great opportunity to wrap together in a model.
Take a look at CompanyInfo.cs:
public class CompanyInfo
{
public string Name { get; set; }
public string Description { get; set; }
}
the About action in HomeController.cs:
public ActionResult About()
{
ViewBag.Username = User.Identity.Username;
var company = new CompanyInfo {
Name = "EBuy: The ASP.NET MVC Demo Site",
32 | Chapter 1: Fundamentals of ASP.NET MVC
Description = "EBuy is the world leader in ASP.NET MVC demoing!", };
return View("About", company);
}
and this snippet from About.cshtml:
@{ var company = (CompanyInfo)ViewData.Model; }
@company.Name
@company.Description
In these snippets, the references to the CompanyName and CompanyDescription dictionary values have been merged into an instance of a new class named CompanyInfo (com pany). The updated HomeController.cs snippet also shows an overload of the View() helper method in action. This overload continues to accept the name of the desired view as the first parameter. The second parameter, however, represents the object that will be assigned to the ViewData.Model property.
Now, instead of setting the dictionary values directly, company is passed as the model parameter to the View() helper method and the view (About.cshtml) can get a local reference to the company object and access its values.
Strongly typed views
By default, the Model property available within Razor views is dynamic, which means that you are able to access its values without needing to know its exact type.
However, given the static nature of the C# language and Visual Studio’s excellent In telliSense support for Razor views, it is often beneficial to specify the type of the page’s model explicitly.
Luckily, Razor makes this pretty easy—simply use the @model keyword to indicate the model’s type name:
@model Auction
@Model.Name
@Model.Description
This example modifies the previous Auction.cshtml example, avoiding the need to add an intermediary variable to cast the ViewData.Model into. Instead, the first line uses the @model keyword to indicate that the model’s type is CompanyInfo, making all references to ViewData.Model strongly typed and directly accessible.
HTML and URL Helpers
The primary goal of most web requests is to deliver HTML to the user, and as such, ASP.NET MVC goes out of its way to help you create HTML. In addition to the Razor markup language, ASP.NET MVC also offers many helpers to generate HTML simply
Views | 33
and effectively. The two most important of these helpers are the HtmlHelper and Url Helper classes, exposed in controllers and views as the Html and Url properties, respectively.
Here are some examples of the two helpers in action:
@Html.ActionLink("Homepage", "Index", "Home")
The rendered markup looks like this:
Homepage
For the most part, the HtmlHelper and UrlHelper types don’t have many methods of their own and are merely shims that the framework attaches behaviors to via extension methods. This makes them an important extensibility point, and you’ll see references to the two types throughout this book.
Though there are far too many methods to list in this section, the one thing to take away at this point is: the HtmlHelper class helps you generate HTML markup and the UrlHelper class helps you generate URLs. Keep this in mind, and turn to these helpers anytime you need to generate URLs or HTML.
Models
Now that we’ve covered controllers and views, it’s time to complete the definition of MVC by discussing models, which are usually considered the most important part of the MVC architecture. If they are so important, why are they the last to be explained? Well, the model layer is notoriously difficult to explain because it is the layer that contains all of the business logic for the application—and that logic is different for every application.
From a more technical standpoint, the model typically consists of normal classes that expose data in the form of properties and logic in the form of methods. These classes come in all shapes and sizes, but the most common example is the “data model” or “domain model,” whose primary job is to manage data.
For example, take a look at the following snippet, which shows the Auction class—the model that will drive the entire EBuy reference application:
public class Auction
{
public long Id { get; set; }
public string Title { get; set; }
public string Description { get; set; }
public decimal StartPrice { get; set; }
public decimal CurrentPrice { get; set; }
public DateTime StartTime { get; set; }
public DateTime EndTime { get; set; }
}
34 | Chapter 1: Fundamentals of ASP.NET MVC
Though we will add various functionality such as validation and behavior to the Auc tion class throughout this book, this snippet is still very representative of a model in that it defines the data that makes up an “auction.”
And, just as we will build on the Auction class throughout the book, be on the lookout for more kinds of classes (such as services and helpers) that all work together to make up the “Model” in “MVC.”
Putting It All Together
So far we’ve described all the parts that make up an ASP.NET MVC application, but the discussion has focused on the code that Visual Studio generates for us as part of the project template. In other words, we haven’t actually made anything yet. So let’s change that!
This section will focus on how to implement a feature from scratch, creating everything you need to accomplish an example scenario: displaying an auction. As a recap, every ASP.NET MVC request requires at least three things: a route, a controller action, and a view (and, optionally, a model).
The Route
To figure out the routing pattern that you’d like to use for a given feature, you must first determine what you’d like your URL for that feature to look like. In this example we are going to choose a relatively standard URL of Auctions/Details/[Auction ID]; for example, http://www.ebuy.biz/Auctions/Details/1234.
What a nice surprise—the default route configuration already supports this URL!
The Controller
Next, we’ll need to create a controller to host the actions that will process the request.
Since controllers are merely classes that implement the ASP.NET MVC controller interface, you could manually add a new class to the Controllers folder that derives from System.Web.Mvc.Controller and begin adding controller actions to that class. However, Visual Studio offers a bit of tooling to take most of the work out of creating new controllers: simply right-click on the Controllers folder and choose the Add > Con troller... menu option, which will pop up the Add Controller dialog shown in Figure 1-8.
Putting It All Together | 35
Figure 1-8. Adding a controller to an ASP.NET MVC application
The Add Controller dialog begins by asking for the name of the new controller class (in this case, we’ll call it AuctionsController) and follows up by asking which scaffold ing template you’d like to use, along with providing a set of options to give you a little bit of control over how ASP.NET MVC is going to generate the new controller class.
Controller templates
The Add Controller dialog offers several different controller templates that can help you get started developing your controllers more quickly:
Empty MVC controller
The default template (“Empty MVC controller”) is the simplest one. It doesn’t offer any customization options because, well, it’s too simple to have any options! It merely creates a new controller with the given name that has a single generated action named Index.
MVC controller with read/write actions and views, using Entity Framework The “MVC controller with read/write actions and views, using Entity Framework” template is just as impressive as it sounds. This template starts with the same output as the “MVC controller with empty read/write actions” template (see below) and then kicks it up a notch, generating code to help you access objects stored in an Entity Framework context and even generating Create, Edit, Details, and Delete views for those objects! This template is a great kick-start when your project uses Entity Framework to access your data, and in some cases the code it generates may be all that you need to support the Read, Edit, Update, and Delete operations for that data.
36 | Chapter 1: Fundamentals of ASP.NET MVC
MVC controller with empty read/write actions
The next option—“MVC controller with empty read/write actions”—generates the same code as the “Empty MVC controller” template, but adds a few more actions that you’ll most likely need in order to expose standard “data access” op erations: Details, Create, Edit, and Delete.
API controller templates
The final three templates—“Empty API controller,” “API controller with empty read/write actions,” and “API controller with read/write actions and views, using Entity Framework”—are the Web API counterparts to the MVC controller tem plates of the same names. We will cover these templates in more detail when we discuss ASP.NET MVC’s Web API functionality in Chapter 6.
An interesting thing to notice about the controller code that Visual Stu
dio generates is that the Index and Details actions each have only one
method, while the Create, Edit, and Delete actions each have two over
loads—one decorated with an HttpPost Attribute, and one without.
This is because Create, Edit, and Delete all involve two requests in order
to complete: the first request returns the view that the user can interact
with to create the second request, which actually performs the desired
action (creating, editing, or deleting data). This is a very common in
teraction on the Web, and you’ll see several examples of it throughout
this book.
Unfortunately, we have not yet reached the point in the book where we are able to use Entity Framework, so for now you can choose the “MVC controller with empty read/ write actions” option and click Add to have Visual Studio generate the next controller class.
After Visual Studio is done creating the AuctionsController, find the Details action and update it so it creates a new instance of the Auction model shown earlier and passes that instance to the view using the View(object model) method.
Yes, this is a silly example. Normally, you’d retrieve this information from somewhere such as a database—and we will show you how to do just that in Chapter 4—but for this example, we are using hardcoded values:
public ActionResult Details(long id = 0)
{
var auction = new Ebuy.Website.Models.Auction {
Id = id,
Title = "Brand new Widget 2.0",
Description = "This is a brand new version 2.0 Widget!", StartPrice = 1.00m,
CurrentPrice = 13.40m,
StartTime = DateTime.Parse("6-15-2012 12:34 PM"),
EndTime = DateTime.Parse("6-23-2012 12:34 PM"),
};
Putting It All Together | 37
return View(auction);
}
The View
With a Details controller action in place and providing data to a view, it’s time to create that view.
As with the controller class in the previous section, you are free to manually add new views (and folders to store them in) directly to the Views folder; however, if you’re the type who prefers a bit more automation, Visual Studio offers yet another wizard to do the work of creating the views—and the folders they live in—for you.
To add a view using the Visual Studio wizard, simply right-click anywhere within the code of the action in a controller and choose the Add View option, which will display the Add View wizard (Figure 1-9). This is actually quite similar to the Add Controller dialog you just used to generate the AuctionsController.
Figure 1-9. Adding a view to an ASP.NET MVC application
The Add View dialog starts off by asking what you’d like to call the new view, defaulting to the name of the controller action from which you triggered the dialog (e.g., Details when called from the Details action). Then, the dialog allows you to choose the syntax
38 | Chapter 1: Fundamentals of ASP.NET MVC
(aka “View Engine”) that you’d like to use when authoring the view. This value defaults to the syntax you chose when you created the web project, but (as promised earlier) you are free to switch between syntaxes if it suits you, perhaps using Razor for some views and the “ASPX” Web Forms syntax for others.
As in the Add Controller dialog, the rest of the options in the Add View wizard have to do with the code and markup that Visual Studio is going to generate when it creates the new view. For example, you can choose to have a strongly typed view model (as discussed in “Strongly typed views” on page 33) by selecting the model type from the list of classes in your project, or typing the type name in yourself. If you choose a strongly typed view, the wizard also lets you choose a template (e.g., Edit, Create, Delete), which analyzes the model type and generates the appropriate form fields for that type.
This is a great way to get up and running quickly and can save you quite a bit of typing, so let’s take advantage of it by checking the “Create a strongly typed view” checkbox, choosing our Auction model from the “Model class” drop-down list, and selecting the Details scaffold template.
Visual Studio will only include in the “Model class” drop-down classes
that it has been able to compile successfully, so if you do not see the
Auction class you created earlier, try to compile the solution and then
open the Add View dialog again.
Finally, you’ll need to tell Visual Studio whether this view is a partial view or should refer to a layout. When you’re using the ASPX Web Forms syntax to author your pages and you choose the “Create as a partial view” option, Visual Studio will create it as a User Control (.ascx) rather than a full page (.aspx). When using the Razor syntax, however, the “Create as a partial view” option has very little effect—Visual Studio creates the same type of file (.cshtml or .vbhtml) for both partial views and full pages. In the case of Razor syntax, the only effect this checkbox has is on the markup that gets generated inside of the new view.
For the purposes of this demo, you can leave the defaults alone: “Create as a partial view” should remain unchecked, while “Use a layout or master page” should be checked, with the layout text box left empty (see Figure 1-10).
Putting It All Together | 39
Figure 1-10. Customizing your view
When you’re ready, click the Add button to have Visual Studio add the new view to your project. After it’s finished, you will see that Visual Studio has analyzed the Auc tion model and generated the required HTML markup—complete with references to HTML helpers such as Html.DisplayFor—to display all of the Auction fields.
At this point, you should be able to run your site, navigate to the controller action (e.g., /auctions/details/1234), and see the details of the Auction object rendered in your browser, as shown in Figure 1-11.
It sure isn’t pretty, but remember, the HTML that Visual Studio generates is just a starting point to help you save time. Once it’s generated, you can feel free to change it however you like.
Congratulations—you have just created your first controller action and view from scratch!
40 | Chapter 1: Fundamentals of ASP.NET MVC
Figure 1-11. The new view rendered in a browser
Authentication
So far we’ve covered just about everything you need to know in order to create an ASP.NET MVC application, but there is one more very important concept that you should know about before you continue with the rest of the book: how to protect your site by requiring users to authenticate themselves before they can access certain con troller actions.
You may have noticed that the Internet Application template generates an AccountCon troller—along with some views to support it—which provides a full implementation of forms authentication right out of the box. This is an acknowledgment that security and authentication are crucial to just about every web application and that, at some point, you’ll probably want to lock down some or all of your site to restrict access to specific users (or groups of users) and prevent unauthorized access by all other visitors. So, since you’ll most likely need it anyway, why shouldn’t Visual Studio generate the controller and views to get you started?
Authentication | 41
The traditional tactic used to lock down ASP.NET applications is to apply authorization settings to specific pages or directories via web.config configuration settings. Unfortu nately, this approach does not work in ASP.NET MVC applications because ASP.NET MVC applications rely on routing to controller actions, not to physical pages.
Instead, the ASP.NET MVC Framework provides the AuthorizeAttribute, which can be applied to individual controller actions—or even entire controllers—to restrict ac cess only to authenticated users or, alternatively, to specific users and user roles.
Take a look at the Profile action on the UsersController that we’ll create later in the book, which displays the profile information for the current user:
public class UsersController
{
public ActionResult Profile()
{
var user = _repository.GetUserByUsername(User.Identity.Name); return View("Profile", user);
}
}
Clearly, this action will fail if the user is not logged in. Applying the AuthorizeAttri bute to this controller action causes any requests made to this action by users who are not authenticated to be rejected:
public class UsersController
{
[Authorize]
public ActionResult Profile()
{
var user = _repository.GetUserByUsername(User.Identity.Name); return View("Profile", user);
}
}
If you’d like to be even more specific about the users who can access the controller action, the AuthorizeAttribute exposes the Users property, which accepts a comma delimited whitelist of acceptable usernames, as well as the Roles property, which accepts a list of allowed roles.
Now, when nonauthenticated users attempt to access this URL, they will instead be redirected to the login URL: the Login action on the AccountController.
The AccountController
In order to help you get a jump-start on your application, the ASP.NET MVC Internet Application project template includes the AccountController, which contains control ler actions that leverage the ASP.NET Membership Providers.
The AccountController provides quite a bit of functionality out of the box, along with the views to support each controller action. This means that your brand new ASP.NET
42 | Chapter 1: Fundamentals of ASP.NET MVC
MVC application already contains the following fully implemented features, without any coding on your part:
• Login
• Logoff
• New user registration
• Change password
Thus, when you apply the AuthorizeAttribute to any of your controller actions, users are redirected to the existing login page that the project template creates for you (see Figure 1-12).
Figure 1-12. The default login page
And, when users need to create a new account in order to log in, they can click the Register link to view the prebuilt Registration page (Figure 1-13).
Plus, if you don’t like the out-of-the-box views, they are easily customizable to meet your needs.
As this section shows, not only does the ASP.NET MVC Framework make it very easy to protect controller actions, but the default project template implements just about everything users will need to authenticate themselves on your site!
Authentication | 43
Figure 1-13. The default registration page
Summary
ASP.NET MVC leverages the time-tested Model-View-Controller architecture pattern to provide a website development framework that encourages loosely coupled archi tecture and many other popular object-oriented programming patterns and practices.
The ASP.NET MVC Framework gets you on the ground running right from the start with helpful project templates and a “convention over configuration” approach that cuts down on the amount of configuration required to create and maintain your ap plication, freeing up more of your time so you can be more productive in getting your application completed and out the door.
This chapter introduced you to the fundamental concepts and basic skills that you need in order to get up and running building ASP.NET MVC 4 applications. The rest of this book will expand on this foundation, showing more features that the ASP.NET MVC Framework has to offer to help you build robust, maintainable web applications using the MVC architectural pattern.
So, what are you waiting for? Keep reading and learn everything you need to know to build the greatest web applications you’ve ever written!
44 | Chapter 1: Fundamentals of ASP.NET MVC
CHAPTER 2
ASP.NET MVC for Web Forms
Developers
Even though their architectural approaches are quite different, ASP.NET MVC and Web Forms actually have a lot in common. After all, they are both built on top of the core ASP.NET APIs and the .NET Framework. So, if you are a Web Forms developer looking to learn the ASP.NET MVC Framework, you’re already further ahead than you may think!
In this chapter, we’ll compare and contrast the ASP.NET MVC and Web Forms Frame works to show how many of the concepts you use to build Web Forms applications relate to the ASP.NET MVC way of doing things. Note that this chapter is geared toward helping developers who are very familiar with the Web Forms Framework and want to translate that knowledge over to ASP.NET MVC to get up and running more quickly. If you are not very familiar with the Web Forms Framework, you may consider skipping this chapter and moving along to the rest of the book.
It’s All Just ASP.NET
You may not have known it, but the framework you’ve been using to develop web pages using the .NET Framework—what you probably call “ASP.NET"—can actually be broken down into two parts: the visual user interface components (aka “Web Forms”) and the nonvisual “backend” web components (aka “ASP.NET”). The two parts are most easily broken down by their .NET namespaces: everything under the System.Web.UI.* namespaces can be considered “Web Forms” and the rest of the Sys tem.Web.* namespaces can be considered “ASP.NET.”
Like Web Forms, ASP.NET MVC (whose classes fall under the System.Web.Mvc.* namespace) is built on top of the strong shoulders of the ASP.NET platform. As such, the two frameworks can be both very similar and incredibly different, depending on how you look at them. This section examines the similarities between the two frame works, while the rest of the chapter continues on to expose their numerous differences.
45
Tools, Languages, and APIs
For starters, both frameworks have access to the full extent of the .NET Framework and everything it has to offer. Naturally, both frameworks rely on the .NET languages of C# and Visual Basic .NET to interact with the .NET Framework, and can access compiled assemblies developed with any other language that the .NET Framework supports.
As a nice side effect, this feature makes your existing ASP.NET code highly reusable. For instance, if you have an existing Web Forms application that accesses data stored in XML files via the System.Xml API, you’ll most likely be able to reuse this code in an ASP.NET MVC application with little or no modification.
It should also come as no surprise that you’ll use Visual Studio to edit ASP.NET MVC websites and the projects they depend on, just like working with Web Forms applica tions (or any other .NET-based applications). You may even notice a few common artifacts, such as web.config and Global.asax, both of which play a large role in both ASP.NET MVC and Web Forms applications.
HTTP Handlers and Modules
Perhaps the most notable parts of the .NET Framework that ASP.NET MVC and Web Forms share are HTTP handlers and HTTP modules. And, even though most classes in the Web Forms API (the System.Web.UI namespace) simply won’t work in an ASP.NET MVC application, HTTP handlers and modules are actually part of the core ASP.NET (System.Web) API, so they are still quite functional in the context of an ASP.NET MVC application. In fact, the ASP.NET MVC pipeline itself starts out by handling incoming requests with an HTTP handler!
Be sure to read about all of the differences between the ASP.NET MVC
and Web Forms Frameworks in this chapter and consider how they
apply to HTTP handlers and modules. Though HTTP handlers and
modules themselves function just fine in an ASP.NET MVC application,
keep in mind that there are certain aspects—such as View State—that
will not work as expected.
Managing State
Managing state—the data related to a user—is an important part of any application, and the stateless nature of the Web makes this a particularly complex task within web applications.
To help deal with state management, ASP.NET Web Forms uses the View State mech anism, wherein state data for a request is serialized and stored in a hidden form field that gets posted back to the server with every subsequent request. View State is such a critical part of the Web Forms platform that nearly every page and component in the
46 | Chapter 2: ASP.NET MVC for Web Forms Developers
framework relies on it at some point. The View State abstraction also has its detriments, though, not the least of which is the fact that every request that contains View State must be a form post and that the potential size of the data in this field—data that is often not even necessary—can become quite large if it is not properly used.
As “State Management” on page 49 explains, ASP.NET MVC’s approach to state management is dramatically different, and in most cases, it leaves state management up to the developer to implement (or not). Most importantly, however, ASP.NET MVC deserts View State completely.
Luckily, the ASP.NET platform offers several state management techniques in addition to View State that continue to work in exactly the same way in ASP.NET MVC. Feel free to use the ASP.NET cache and session state, or even the HttpContext.Items APIs, just as you always have to help manage state in ASP.NET MVC applications.
Deployment and Runtime
ASP.NET MVC websites get deployed to the same kind of production environment as Web Forms applications. This means that just about everything you’ve already learned about deploying and maintaining an ASP.NET application—e.g., to do with Internet Information Server (IIS), .NET application pools, tracing, troubleshooting, and even deploying assemblies’ bin folders—continues to be quite relevant to deploying and maintaining ASP.NET MVC applications. Though ASP.NET MVC and Web Forms applications follow quite different architectures, in the end it’s all .NET code that gets deployed and executed to process HTTP requests.
More Differences than Similarities
The number of similarities that the previous section pointed out may have you thinking that ASP.NET MVC and Web Forms seem almost like the same framework. As you analyze the two frameworks more deeply, however, it becomes quite clear that they are much more different than their numerous similarities make them seem.
Table 2-1 illustrates this fact, comparing and contrasting a number of the frameworks’ core components.
Table 2-1. Fundamental differences between ASP.NET MVC and Web Forms Web Forms ASP.NET MVC
Views tightly coupled to logic View and logic kept very separate
Pages (file-based URLs) Controllers (route-based URLs)
State management (View State) No automatic state management
Web Forms syntax Customizable syntax (Razor as default)
Server controls HTML helpers
More Differences than Similarities | 47
Web Forms ASP.NET MVC
Master pages Layouts
User controls Partial views
Please note that—especially since both frameworks are built on top of
the ASP.NET platform—in many ways it is quite possible to make Web
Forms behave more like ASP.NET MVC, and vice versa. That is to say,
you are certainly able to apply many MVC techniques to Web Forms
applications, and vice versa.
However, keep in mind that the comparisons made throughout this
chapter refer to the standard development practices for each framework,
i.e., the way you see things done in “official” channels such as the API
documentation and tutorials.
Separation of Application Logic and View Logic
The most important difference between ASP.NET MVC and Web Forms is the funda mental architectural concepts they each employ.
For instance, Web Forms was introduced (ironically enough) to provide a better sep aration of concerns than its predecessor, the ASP Framework, which effectively forced developers to combine their business logic and markup in one single file. Web Forms not only gave developers the ability to separate their business logic from their markup, it also provided a much more powerful development platform—the .NET Frame work—in which to write the code that drove that business logic. But despite all of the advantages that Web Forms provided over traditional ASP scripts, the Web Forms architecture is still very much focused on “the page”; though the code is moved to another location, it is still quite difficult to truly separate the business logic that handles a request from the view that the user sees.
ASP.NET MVC, on the other hand, is built from the ground up on the concept of separation of concerns driven by loosely coupled components that work together to process a request. This approach not only benefits the development lifecycle by in creasing the ability to develop individual components in relative isolation, as well as the ability to test those components, but it also provides the ability to handle requests much more dynamically, as the next section demonstrates.
URLs and Routing
Under the Web Forms architecture, every one of a website’s external URLs is repre sented by a physical .aspx page, and each of those pages is tightly coupled to a single optional class (aka “code-behind”) that contains the logic for the page. Pages cannot dynamically choose the class they are bound to, and code-behind classes cannot render alternate views.
48 | Chapter 2: ASP.NET MVC for Web Forms Developers
The Web Forms page-based approach stands in stark contrast to the way that ASP.NET MVC handles requests, relying instead on potentially complex routing rules to dynam ically map external URLs to the appropriate controller actions and allowing the con troller action logic to dictate which view will be displayed to the user.
For instance, the pipeline may respond differently to a user navigating to the URL / auctions/details/123 in her browser than it responds to an AJAX request to that same URL, simply based on the fact that the AJAX request contains a special header that identifies it as an AJAX request. In the case of the user navigating directly to the URL, the server may return a full web page complete with HTML, JavaScript, and CSS, whereas the server may respond to the AJAX request with only the serialized data for the requested Auction and nothing more. What’s more, the server may even choose to serialize the Auction data in different formats—e.g., JSON or XML—based on aspects of the request such as the value of a query string parameter.
This kind of dynamic processing is simply not something that the Web Forms Frame work easily supports without resorting to the use of HTTP modules or HTTP handlers.
ASP.NET’s routing functionality is not limited to ASP.NET MVC ap
plications—it can also be used to customize the URLs in a Web Forms
application.
The primary difference between the two uses is that routing is such a
critical component in the ASAP.NET MVC architecture that the frame
work could not operate without it, whereas Web Forms applications
primarily use routing to avoid page file path restrictions and to gain
better control over their URLs.
State Management
Perhaps the most controversial difference between Web Forms and ASP.NET MVC is how they each handle the user’s state across requests—specifically, ASP.NET MVC ditches View State. How can something so fundamental be completely removed? The short answer is that ASP.NET MVC embraces the stateless nature of the Web. However, to gain a better idea of what this really means, let’s revisit the history of Web Forms one more time.
In addition to providing a better development platform than ASP, one of the original goals for the Web Forms Framework was to bring “thick,” native client application development techniques—such as “drag and drop” and other Rapid Application Development (RAD) concepts—to the Web.
In order to bring the Web and native client development experiences closer together, Web Forms had to create a layer of abstraction on top of fundamental web development concepts such as HTML markup and styling. One of the most significant concepts in native application development is that a native application is stateful, which means that
More Differences than Similarities | 49
the application is aware of the state of its interaction with the user and can even persist that state in order to reuse it across instances of the application.
The Web, on the other hand, is based on HTTP requests, with each request involving a single client request and a single server response. A web server must handle every HTTP request in isolation, unaware of any previous or future messages that may be exchanged with a given client—in effect, preventing the server and the client from having an on-going conversation in which the server is able to remember its previous interactions with the client.
In order to apply stateful interactions across a stateless medium, an abstraction must be applied—thus View State was born. Simply put, View State serializes the state of the interaction between the client and the server and stores that information in a hidden form field on every page that the server sends to the client. It’s then the client’s re sponsibility to pass along this serialized state on every subsequent request in the conversation.
Rather than attempt to duplicate this abstraction, ASP.NET MVC embraces the state less nature of the Web and provides no out-of-the-box alternative to View State other than server-side techniques such as caching and session state. Instead, ASP.NET MVC expects requests to include all the data that the server needs in order to process them. For instance, rather than retrieving an Auction from the database and serializing the whole object down to the client so the client can send the Auction object back during subsequent requests, ASP.NET MVC responses might reply with simply the Auction’s ID. Then, subsequent requests will include just the Auction’s ID, which the ASP.NET MVC controller processing the request uses to retrieve the Auction from the database for each request.
Clearly, both approaches have their benefits and trade-offs. Whereas View State makes many ongoing client interactions much simpler, the data contained within it can quickly and easily become unwieldy, using up a significant amount of bandwidth for data that may never be used. In other words, View State is meant to make developers’ lives easier without their having to think about it, but it comes at the cost of increased bandwidth, particularly when developers do not stop to consider what data their pages are storing.
ASP.NET MVC’s approach, on the other hand, may decrease page sizes, but at the cost of increased backend processing and (perhaps) database requests in order to fully re hydrate the request’s state on the server.
Rendering HTML
Every website is different, but one thing all websites have in common is that their need to generate HTML. One of the primary requirements for any web application frame work is the ability to help developers render that HTML as productively as possible. Both ASP.NET MVC and Web Forms do this very well—but they do so in drastically different ways.
50 | Chapter 2: ASP.NET MVC for Web Forms Developers
Web Forms views are easily distinguishable at a glance; just about everything in Web Forms views—from