Scott Hanselman

ModelBinders are great. I've blogged a bit about them before like the File Upload Model Binder.

I am working on some code like this:

[Authorize]
public ActionResult Edit(int id) {

    Dinner dinner = dinnerRepository.FindDinner(id);

    if (dinner.HostedBy != User.Identity.Name)
        return View("InvalidOwner");

    var viewModel = new DinnerFormViewModel {
        Dinner = dinner,
        Countries = new SelectList(PhoneValidator.Countries, dinner.Country)
    };

    return View(viewModel);
}

It's pretty straight forward, but this Controller knows too much. It's reaching into implicit parameters. The id was passed in, but the User is actually a property of the Controller base class and ultimately requires an HttpContext. Having this method "know" about the User object, and worse yet, having the User object go reaching into HttpContext.Current makes this hard to test.

I'd like to have the convenience of passing in the User (actually an IPrincipal interface) when I want to test, but when I'm running the app, I'd like to have the IPrincipal get passed into my method automatically. Enter the Model Binder. I need to teach ASP.NET MVC what to do when it sees a type as a parameter.

This quickie model binder is now responsible for one thing - it knows how to reach down into the HttpContext and get the current User (IPrincipal). It has one single responsibility.

public class IPrincipalModelBinder : IModelBinder
{
    public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        if (controllerContext == null) {
            throw new ArgumentNullException("controllerContext");
        }
        if (bindingContext == null) {
            throw new ArgumentNullException("bindingContext");
        }
        IPrincipal p = controllerContext.HttpContext.User;
        return p;
    }
}

Now I can release the Controller from the emotional baggage of knowing too much about the User object. It can just have that passed in automatically by the framework. I just need to register the binder to tell folks about it. I can either do it on a one-off basis and put an attribute on this one method parameter:

public ActionResult Edit(int id,                        
                         [ModelBinder(typeof(IPrincipalModelBinder))]                        
                         IPrincipal user)
{...}

But even better, I can just tell the whole application once in the global.asax:

void Application_Start() {
    RegisterRoutes(RouteTable.Routes); //unrelated, don't sweat this line.
    ModelBinders.Binders[typeof(IPrincipal)] = new IPrincipalModelBinder();
}

Now that ASP.NET MVC knows what to do when it see an IPrincipal as a method parameter, my method gets nicer.

[Authorize]
public ActionResult Edit(int id, IPrincipal user) {

    Dinner dinner = dinnerRepository.FindDinner(id);

    if (dinner.HostedBy != user.Identity.Name)
        return View("InvalidOwner");

    var viewModel = new DinnerFormViewModel {
        Dinner = dinner,
        Countries = new SelectList(PhoneValidator.Countries, dinner.Country)
    };

    return View(viewModel);
}

Now I can test my controller more easily by passing in fake users. No need for mocking in this case!

[TestMethod]
public void EditAllowsUsersToEditDinnersTheyOwn()
{
    // Arrange
    DinnersController controller = new DinnersController(new TestDinnerRespository());

    // Act
    IPrincipal FakeUser = new GenericPrincipal(new GenericIdentity("Scott","Forms"),null);
    ViewResult result = controller.Edit(4, FakeUser) as ViewResult;

    // Yada yada yada assert etc etc etc
    Assert.IsTrue(result.ViewName != "InvalidOwner");
}

Fun stuff.

UPDATE: Phil had an interesting idea. He said, why not make method overloads, one for testing and one for without. I can see how this might be controversial, but it's very pragmatic.

[Authorize]
public ActionResult Edit(int id)
{
    return Edit(id, User); //This one uses HttpContext
}

You'd use this one as before at runtime, and call the overload that takes the IPrincipal explicitly for testing.

Yes, I realize I could use an IoC container for this also.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By