Brad Wilson

ASP.NET MVC 3 Service Location, Part 3: View Engines/View Pages

Series Index

• Part 1: Introduction
• Part 2: Controllers
• Part 3: View Engines and View Pages
• Part 4: Filters
• Part 5: IDependencyResolver
• Part 6: Model Validation
• Part 7: Model Metadata
• Part 8: Value Providers
• Part 9: Model Binders
• Part 10: Controller Activator
• Part 11: View Page Activator

Important Update

We've made significant changes to the IoC support in ASP.NET MVC 3 Beta. Please read Part 5 for more information.

View Engine Registration and View Page Creation

ASP.NET MVC 1.0 introduced View Engines (implementing IViewEngine and IView), shipping with the single WebForms-based view engine. Views, master pages, and partial views in WebForms view engine need to derive from ViewPage, ViewMasterPage, and ViewUserControl (respectively). In MVC 3, we've introduced new dependency injection points for all of these classes (plus the new base class for Razor views, WebViewPage).

Update: (31 July 2010) I've added the source code for UnityMvcServiceLocator to the end of part 2.

ASP.NET MVC 3 Service Location, Part 2: Controllers

Series Index

• Part 1: Introduction
• Part 2: Controllers
• Part 3: View Engines and View Pages
• Part 4: Filters
• Part 5: IDependencyResolver
• Part 6: Model Validation
• Part 7: Model Metadata
• Part 8: Value Providers
• Part 9: Model Binders
• Part 10: Controller Activator
• Part 11: View Page Activator

Important Update

We've made significant changes to the IoC support in ASP.NET MVC 3 Beta. Please read Part 5 for more information.

Controller Creation

The most common form of service location today in ASP.NET MVC is for controller creation. In MVC 1.0, we created an interface named IControllerFactory which is responsible for the location and creation of controllers. This interface was introduced with the explicit desire to support dependency injection of controllers.

Update: (31 July 2010) I've added the source code for UnityMvcServiceLocator to the end of this post.

ASP.NET MVC 3 Service Location, Part 1: Introduction

Series Index

• Part 1: Introduction
• Part 2: Controllers
• Part 3: View Engines and View Pages
• Part 4: Filters
• Part 5: IDependencyResolver
• Part 6: Model Validation
• Part 7: Model Metadata
• Part 8: Value Providers
• Part 9: Model Binders
• Part 10: Controller Activator
• Part 11: View Page Activator

Important Update

We've made significant changes to the IoC support in ASP.NET MVC 3 Beta. Please read Part 5 for more information.

Introduction

One of the new features in ASP.NET MVC 3 is the ability to register a service locator that will be used by the framework. Prior versions of the MVC framework have offered opportunities for introducing concepts like service location and dependency injection (DI); in MVC 3, we have formalized the process and opened up several new opportunities for developers.

This first post in the series will discuss the general strategy for service location in MVC 3. Later posts will discuss specific ways to perform service location and DI with existing and new features.

Testing Routing and URL Generation in ASP.NET MVC

In ASP.NET MVC, getting your routes setup properly can be tricky if you have a lot of routes. Whenever something is tricky, and might be touched often, having a set of unit tests around it can very helpful to ensure you aren't breaking it when you make changes. Lots of routes can definitely qualify; your users rely on unbroken links and stable URLs for a good experience.

The techniques shown here not only work for unit testing, but can also be used outside of the ASP.NET pipeline when you need to interact with the routing system (for example, to generate URLs from a service). The routing system used by ASP.NET MVC uses the abstraction classes, so the actual running ASP.NET pipline isn't required.

What's New in xUnit.net 1.6

Yesterday we pushed the shiny red button to send you all the bits for xUnit.net 1.6. It turns out there were some interesting technical challenges behind the scenes, so after I do the obligatory feature list, I'll talk about all the work we did (and sometimes undid) along the way.

Advanced ASP.NET MVC 2 (CodeCamp Edition)

I just published the slides and code for my CodeCamp version of the Advanced MVC 2 talk. This talk is different from the C4MVC talk in that I did a 10 minute intro to what's new in MVC 2, and a few of the demos were re-worked. In particular, I included a RESTful resource registration helper and automatic controller, both available in the sample project.

The video was streamed, and should be available for on-demand viewing soon.

(The Presentations page of my blog includes all my past presentations.)

Is ASP.NET MVC Exposing My Secrets?

Let's suppose you have a model like this:

public class User {
    public string Username { get; set; }

    [DataType(DataType.Password)]
    public string Password { get; set; }
}

To test this out, you write an action:

public ActionResult Index()
{
    return View(new User { Username = "brad", Password = "secret" });
}

And an editor in the view:

<% using (Html.BeginForm()) { %>
    <%: Html.EditorForModel() %>
    <input type="submit" />
<% } %>

You pop up the browser and notice that the password field looks like it's already filled out. Uh oh! View Source...

<input class="text-box single-line" id="Username" name="Username" type="text" value="brad" />
<input class="text-box single-line password" id="Password" name="Password" type="password" value="secret" />

Don't panic. Believe it or not, this actually isn't a bug. I sorta tricked you by using a model that you shouldn't have in the real world. :)

To start with, you're not storing your passwords in clear text are you? You shouldn't be, because cleartext passwords are just begging to be stolen and exploited. Sites should be using an irreversible one-way hash (like SHA-1) to store passwords for their users. In practice, your model won't have an unencrypted password hanging out in it where it can be exposed like this.

Why did we allow the value of the property out into the editor?

Sometimes you want to offer an editor form which, among other things, allows the user to pick a new password. Additionally, an empty password is valid for the new password value, so you can't use empty to indicate that the password wasn't set. In this case, it's common to pre-fill the password field with a garbage "sentinel" value (like a GUID) so you can easily tell whether the user typed something, including clearing the field. Because we let you set a value in your model, it allows you to set one of these sentinel values for your form. If we didn't allow this, you'd have to ignore/avoid our password HTML helper and write your own.

Advanced ASP.NET MVC 2

My re-recorded Advanced ASP.NET MVC 2 video is available now. The original video, from my C4MVC presentation, turned out to have a combination of bad audio and bad video, most of which I take the blame for, so I re-recorded everything in my office this past Monday. Eric has uploaded the new video, which I've included below.

Update: I've provided a downloadable version of the video here.

Diagnosing ASP.NET MVC Problems

Update: (Dec 5, 2010) The Diagnostics page is available on NuGet now. For more information, see Phil Haack's blog post. Since we rev this page with every release of MVC, NuGet is an excellent release vehicle, because it allows you to always have quick access to the latest version.

When we released ASP.NET MVC 2, we included a file in the MvcFutures package (download) called MvcDiagnostics.aspx.

This single WebForms page can be dropped into any MVC site, and then viewed in your browser. It will give you diagnostic information about ASP.NET MVC, which can be very helpful when trying to figure out why your MVC application isn’t working. (It’s a WebForms page because, if MVC is broken for you, what good would an MVC page be? :) )

Two common problems we see on the forums include:

• Version mismatch between MVC and MvcFutures. This will detect that situation and let you know that your versions are mismatched.
• Problems where a site works locally but fails when put into a hosted environment. This usually happens because of mismatched or missing MVC dependencies, both of which this can help you detect.

Don’t be surprised if we ask you to run this page to help us help you diagnose issues with your MVC applications. :)

This utility knows about many versions of MVC, including all the version numbers for MVC since 1.0 Preview 2. Despite the fact that we’ve put it in the MVC 2 Futures download, it can be used to detect problems for both MVC 1.0 and MVC 2 applications.

Here’s what it looks like when I drop it in a new MVC 2 site:

Hope that helps!

Remote Validation with ASP.NET MVC 2

One validation feature that we didn’t quite have time for in MVC 2’s new client-side validation support is called “remote validation”.

Remote validation means we make a call back to our web site to ensure that a given value is valid. You might want this in cases where it’s not easy (or possible) to determine whether the value is valid on the client side, but you’d still like to give the user client-side feedback about the validity of the item. The canonical example is checking to see if a desired username is taken during your site registration process.