K. Scott Allen

Pretty Code #1 – Building SelectListItems

scott — Fri, 03 Jul 2009 04:11:00 GMT

In ASP.NET MVC, you can use a collection of SelectListItems to help build an HTML <select>. Just watch out for the HTML helper overloads. The question is – what is the prettiest code that can change a list of Products into a collection of SelectListItems?

Tonight, you’ll be the judge in this first contest of charm, grace, and readability.

Contestant #1 hails from the System.Web.Mvc namespace. It likes pina coladas and string literals, but is turned off by tattoos that look like programming symbols. Let me introduce the SelectList class:

var products = GetProducts();
var selectItems = new SelectList(products, "ID", "Name");

Contestant #2 lives in the System.Linq namespace. It likes whips and method chains. Functional programmers call it “map”, but in .NET we call it "Select":

var selectItems = from product in GetProducts()
                  select new SelectListItem 
                  {
                      Text = product.Name,
                      Value = product.ID.ToString()
                  };

… or (from the backside) …

var selectList = GetProducts().Select(product =>
                    new SelectListItem
                    {
                        Value = product.ID.ToString(),
                        Text = product.Name 
                    });

Contestant #3 lives in the MvcContrib project. It’s turned on by pointy things and practices yoga for extensibility. Introducing the ToSelectList method:

var selectItems = GetProducts().ToSelectList(product => product.ID,
                                             product => product.Name);

Personally, I like #2. While the name of #3 makes its purpose obvious, it sometimes takes a moment to be 100% clear about what property becomes Text, and what property becomes Value. In #2 the Text and Value assignments are obvious, even though the code is a little longer. Setting the Selected properties with either approach is trivial.

What do you think?

Three IIS Concepts ASP.NET Developers Should Know

scott — Wed, 01 Jul 2009 23:37:00 GMT

It’s possible to do a lot of work with ASP.NET and not know anything about IIS, particularly if you work with a large team where IT specialists keep the riff-raff away from production web applications. Ever since Visual Studio started shipping its own web server¹, many people don’t rely on IIS for day to day development work (although many of us still do).

For those of you who are just learning how to deploy in IIS, or those of you who need a refresher, I put together a short and free Pluralsight screen cast on IIS: Web Sites, Applications, and Virtual Directories in IIS

This is one video in a collection of screencasts from Pluralsight.

1) Some people call the web server “Cassini”. Other people call it the “WebDev” server. Still others call it “the web thingy that sits in my system tray”, even though Windows doesn’t have a system tray, but whatever. If you worked with the first release of Visual Studio, you’ll know we’ve come a long way from running as an administrator with Front Page Extensions installed and the IDE trying to force all of our code to live underneath inetpub\wwwroot <shudder />.

Principles, Code-Behind, & View Engines

scott — Mon, 29 Jun 2009 08:10:00 GMT

The July issue of MSDN Magazine is available online with my article “Guiding Principles For Your ASP.NET MVC Applications”. Another MVC article in this issue is Justin Etheredge’s “Building Testable ASP.NET MVC Applications”. Justin’s article is a good one as he shows you how to design for testability, and includes specific examples with xUnit.net, moq, and Ninject.

Something we both touched on was the topic of code-behind files.

Code-Behind and ASP.NET MVC

The conversation between two developers (let’s call them Pushy and Principled), goes like this:

Pushy: Is it OK to use code-behind files with aspx views?

Principled: No.

Pushy: But, I have something that’s really, really specific to this one particular view. That’s OK, right?

Principled: No.

Pushy: Oh, come on! You aren’t being pragmatic here. I don’t want to add a Page_Load, I just need a teeny tiny little instance method. I’ll add a code-behind file and stick it inside. It’s tiny! That’s OK, right?

Principled: No.

Pushy: Really now, what do you expect me to do? Build one of those forsakenly awful HTML helper methods with more overloads than the California power grid in August? Don’t you think it’s better to put the code close to the view that uses it?

Principled: No.

This is one scenario where I’d side with Principled. Sure, the code-behind could be simple. Sure, if you are careful it might even be unit-testable. But, the mere fact that code-behind is possible is a fluke and a byproduct from building on an existing framework. Someone writing an MVC view engine from scratch wouldn’t need to provide such a feature that allows you to put anything resembling intelligence near a view.

All of the problems I’ve seen described where code-behind is a solution could easily be solved with an HTML helper, or by using a more robust presentation model that is passed to the view. Some people worry about a proliferation of HTML helpers, but if you absolutely need a helper scoped to a specific view, you can always put the helper in a different namespace that only that particular view will use.

I know your team is disciplined. I know you wouldn’t do anything wrong. I know you want to be pragmatic and do the simplest thing that works. But, think of the first code-behind file in a project as the first broken window. It’s another degree of freedom where entropy can wiggle into your software and undermine maintainability. It’s making a view smarter, which your principles should suggest is wrong.

Thoughts?

Functional Programming Battles GOTOzilla

scott — Wed, 17 Jun 2009 01:53:00 GMT

Steve Wellens had a recent blog post arguing for the use of a goto in C# (see: Why goto Still Exists in C#). Steve had a series of methods he wants to execute, but he wants to stop if any given method returns false. At the end of the post, Steve decided that the following code with goto was better than setting boolean variables:

 // DoProcess using goto
void DoProcess3()
{
    LOG("DoProcess Started...");

    if (Step1() == false)
        goto EXIT;
    if (Step2() == false)
        goto EXIT;
    if (Step3() == false)
        goto EXIT;
    if (Step4() == false)
        goto EXIT;
    if (Step5() == false)
        goto EXIT;

EXIT:
    LOG("DoProcess Finished");
}

In the comments, a remark from a different Steve stood out. Steve suggested using an array of Func<bool>. The comment didn’t generate any further discussion, but it’s worthy to call out.

I don’t think the problem with the above code is with the goto per-se. I think the problem is how the code conflates “what to do” with “how to do it”. In this scenario both are a little bit tricky. Let’s assume we might need to add, remove, or change the order of the method calls. But, the method calls are so intertwined with conditional checks and goto statements that it obscures the process. Using an array of Func<bool> is a simple approach, yet it still manages to create a data structure that isolates “what to do”.

void Process()
{
    Func<bool>[] steps =
    {
        Step1,
        Step2,
        Step3,
        Step4,
        Step5
    };

    ExecuteStepsUntilFirstFailure(steps);
}

You could argue that all this code does is push the problem of “how to do it” further down the stack. That’s true, but we’ve still managed to separate “what” from “how”, and that’s a big win for maintaining this code. The simplest thing that could possibly work for “how” would be:

void ExecuteStepsUntilFirstFailure(IEnumerable<Func<bool>> steps)
{
    steps.All(step => step() == true);
}

The All operator is documented as stopping as soon as a result can be determined, so the above code is equivalent to the following:

void ExecuteStepsUntilFirstFailure(IEnumerable<Func<bool>> steps)
{
    foreach (var step in steps)
    {
        if (step() == false)
        {
            break;
        }
    }

With this approach it’s easy to change the order of the steps, or to add steps and delete steps, without worrying about missing a goto or conditional check. The next step up in complexity (excuse the pun) would be to create a Step class and encapsulate the Func with other metadata and state. I’m sure you could also imagine the execution phase relying on an IStepExector interface as the base for executing steps under a transaction, or with step-level logging, or even in parallel – and all this without changing how the steps are arranged. Take this to an extreme, and you’ll have a technology like Windows Workflow Foundation. :)

The ability of functional and declarative programming to separate the “what” and the “how” is powerful, but you don’t need a new language, and you can start simple. In this scenario it’s another tool you can use to save your city from the goto-zilla monster.

What do you think?

Progressive .NET Event In Stockholm

scott — Wed, 10 Jun 2009 08:49:00 GMT

Øredev is putting together an exciting lineup of topics and speakers for Progressive .NET Days. The event is August 27-28 in Stockholm Sweden.

Progressive software development understands that tomorrow's better ideas for software development are likely here with us today and seeks them out now, building bridges that span paradigms through practice and experience.

I’m excited to be a part of the event, and wish I could also sit in on every other session.I’ve also had a dream to ride in a hot air balloon, which I understand is quite popular during the summer months in Stockholm….

When Do I Use Interfaces?

scott — Mon, 08 Jun 2009 06:50:00 GMT

“Program to an interface, not an implementation” is a well-known mantra from the GoF book. Take this guidance to an extreme, though, and you generate POO instead of OOP. How do know if you crossed the line?

I think it’s useful to take a step back and think about the word “interface” in a general sense. There are interfaces everywhere in software. There are interfaces between layers, between tiers, between applications, between objects, and between callers and their callees. Just about anything and everything in software, no matter how trivial, has an interface.

The real question with interfaces is how many constraints you want in place for any given interface. Consider the following JavaScript code.

function validate(creditService) {
    creditService.checkCreditForCustomer(this.id);
}

The only constraint on the creditService parameter is that the object needs a checkCreditForCustomer function that takes an ID parameter. The validation function doesn’t care how the creditService was built, who built it, where it came from, or what other capabilities might be in place. This code demonstrates the flexible, dynamic, and relatively unconstrained qualities of duck typing. If the parameter checks the credit of a customer like a credit service should, then it must be a credit service.

Going Static

Static languages generally have to crank up the constraints on an interface, although many have an escape hatch. C# 4.0, for example, introduces a dynamic type.

public bool Validate(dynamic creditService)
{
    return creditService.CheckCreditForCustomer(ID);
}

Again - all we need is an object with a CheckCreditForCustomer method that takes an int parameter. Because the object is typed as dynamic, the compiler won’t guarantee what the object can actually do – there is no type checking. At runtime, we may find out the object doesn’t actually support the method we are looking for, and an exception appears. This duck typing behavior is what keeps fans of static typing awake at night. They think the dynamic programmers are insane for throwing around objects in a willy-nilly manner. Meanwhile, the dynamic crowd thinks the fans of static typing are insane for spending all of their time obsessing over types instead of creating software.

Regardless of where you fall in the static to dynamic spectrum, you can view a type definition as a constraint. In C# and Java, the interface keyword can constrain the type of an object without placing any constraints on the implementation.

interface ICreditService
{
    bool CheckCreditForCustomer(int id);
    bool CheckCreditForCompany(int id);
}

Now we can use this constraint to enforce type safety.

public bool Validate(ICreditService creditService)
{
    return creditService.CheckCreditForCustomer(ID);
}

An interface (in the interface keyword sense) allows fans of static typing to sleep at night while still leaving some flexibility behind. The object that arrives as an ICreditService on any given call might be one of 10 different credit service implementations. The 10 implementations may be from the same class inheritance hierarchy, or they may not. One might be a mock object or test double used only during testing (which I should point out is not, not, not the point of using interfaces), or it may not. The Validate doesn’t care about the concrete implementation behind the interface.

We still have some flexibility, but we also have additional constraints when compared to duck typing. The credit service has to implement two methods now, even if we just want to build an object for the Validate method which only uses the CheckCreditForCustomer method. These two methods may or may not be good thing. Iterative design with tests and a dose of the interface segregation principle will take care of the matter.

Going Concrete

Even more constraints come into play if we use a class definition instead of an interface.

public class CreditService
{
    public virtual bool CheckCreditForCustomer(int id)
    { 
        // ...
    }
    
    // ...
}

Now we’ve not only constrained the type, but we’ve constrained the implementation. Whoever provides our credit service functionality must be a CreditService object, or use CreditService as a base class. Building software is all about composing pieces of functionality together, and using a concrete class as the interface specification places hard restrictions on how the composition will work now,and in the future.

Interfaces Everywhere?

Sometimes, these hard restrictions make sense, or at least aren’t important. For example, classes that have no behavior (like DTOs) don’t need an interface abstraction. I’ve also never found it useful to specify entities using an interface, as they have pure business logic inside (logic dealing only with other business objects or abstractions).

public interface ICustomer
{
    int ID { get; set; }          
    int Name { get; set; }
    void UpdateAddress(/* ... */);
    // ...
}

In short, you don’t need interfaces everywhere, you need to anticipate where your software needs to be flexible, which isn’t always easy. Using interface definitions between two horizontal or vertical layers of an application is almost always a yes, but programming to an interface between two business objects inside the same context is a definite maybe.

I like to use interface definitions when I want to turn a detail into a concept. For example, I’d feel more comfortable with an business object using an ISendMessage object then an SmtpServer object. The concept is closer to what the object needs to do (send a message), and it’s easier to change the business object’s behavior by giving the object a different ISendMessage implementation. As a special extra double bonus, the object using ISendMessage is much easier to test. List<T> is a detail. IList<T> is a concept.

If you doubt the power of interface programming, then just look at COM. Really. In COM you could only program to an object’s interface, and this allowed objects from different runtimes (Visual Basic versus C), different threading models (objects with a thread affinity versus multi-threaded objects), and different processes (local versus remote) to all work together, plus a host of other features. Interface definitions are the ultimate abstraction (for a statically typed environment!).

From LINQ to XPath and Back Again

scott — Fri, 05 Jun 2009 07:52:00 GMT

Let’s say you wanted to select the parts for a Lenovo X60 laptop from the following XML.

<Root>
  <Manufacturer Name="Lenovo=">
    <Model Name="X60=" >
      <Parts>
        <!-- ... -->
      </Parts>
    </Model>
    <Model Name="X200=">
      <!-- ... -->
    </Model>
  </Manufacturer>
  <Manufacturer Name="...=" />
  <Manufacturer Name="...=" />
  <Manufacturer Name="...=" />
  <Manufacturer Name="...=" />
</Root>

If you know LINQ to XML, you might load up an XDocument and start the party with a brute force approach:

var parts = xml.Root
               .Elements("Manufacturer")
                   .Where(e => e.Attribute("Name").Value == "Lenovo")
               .Elements("Model")
                   .Where(e => e.Attribute("Name").Value == "X60")
               .Single()
               .Element("Parts");

But, the code is ugly and makes you long for the days when XPath ruled the planet. Fortunately, you can combine XPath with LINQ to XML. The System.Xml.XPath namespace includes some XPath specific extension methods, like XPathSelectElement:

string xpath = "Manufacturer[@Name='Lenovo']/Model[@Name='X60']/Parts";
var parts = xml.Root.XPathSelectElement(xpath);

Now the query is a bit more readable (at least to some), but let’s see what we can do with extension methods.

static class ComputerManufacturerXmlExtensions
{
    public static XElement Manufacturer(this XElement element, string name)
    {
        return element.Elements("Manufacturer")
                      .Where(e => e.Attribute("Name").Value == name)
                      .Single();
    }

    public static XElement Model(this XElement element, string name)
    {
        return element.Elements("Model")
                      .Where(e => e.Attribute("Name").Value == name)
                      .Single();
    }

    public static XElement Parts(this XElement element)
    {
        return element.Element("Parts");
    }
}

Now, the query is short and succinct:

var parts = xml.Root.Manufacturer("Lenovo").Model("X60").Parts();

Combine an XSD file with T4 code generation and you’ll have all the extension methods you’ll ever need for pretty XML queries...

Catching Up On Lean

scott — Thu, 04 Jun 2009 06:59:00 GMT

I now have a number of lean software development books queued up. It started when I saw this single bullet point in a presentation:

Overproduction == Extra Features

I’m enjoying the thinking behind lean, and I believe the techniques and vocabulary of lean makes software development more tangible to the folks we work with who don’t write code – and that’s important.

Overproduction in software development happens when you produce a feature that customers rarely use. This is one of lean’s seven deadly types of wastes. The perfect technique to manage this waste is to never create a feature without first establishing a clear value for the feature, but perfection isn’t easy. In commercial software development you’ll inevitably ship some useless bits as you discover the market and the functionality your future customers will value.

Even when you do ship successful bits, the outside world can reprioritize your software. The U.S. healthcare industry, for example, is ultra-sensitive to laws and regulations. A new piece of legislation can change last year’s “must have” feature into this year’s “meh”.

Breaking Up Is Hard To Do

The relationship between overproduction stuck out to me because I’ve wrestled with overproduction for many years on several different products. Software vendors are reluctant to remove features, no matter how rarely used the features may be. Sales people in particular object to cutting anything they think might possibly have the slightest potential to attract a single future sale.

The basic problem is thinking of a software feature as an investment -something to protect moving forward. As Mark Lindell will tell you, code is not an investment but a liability. In lean thinking, features are inventory, and anyone who has come within spitting distance of a business school knows inventory can make cuts in the margin.

Removing a working feature is never an easy decision, but the sooner a vendor sees obsolete features as a cost and waste, the sooner the vendor can jettison the unused inventory that adds no value to the customer or the company.

Don't Ask Me If It's Possible

scott — Wed, 03 Jun 2009 04:11:00 GMT

Years ago, ex-Googler Doug Edwards wrote a blog post to explain the meaning behind a few favorite words in the software developer’s vocabulary: orthogonal, cruft, canonical, and the big one - non-trivial.

Non-trivial
It means impossible. Since no engineer is going to admit something is impossible, they use this word instead.

I’ve spent the bulk of my career developing commercial software, and it’s amazing how many sales people, executives, and marketing managers ask if something is possible. Example:

Is it possible to reverse the flow of time when we click this button?

The requests are more realistic, of course, but the stock reply is:

Given enough resources, anything is possible.

The response doesn’t say the feature is impossible, or even non-trivial. You might think the response is the habitual reply of yet another passive-aggressive software developer (the canonical developer, to use Mr. Edward’s lexicon), but I much prefer to think of the reply as a zen-like answer that points the questioner to the realities of software development. Despite what the pointy haired boss hears from tool vendors and analysts, creating software still requires resources – both time and mental effort.

What I’ve Learned

Building commercial software for a vertical market is a … non-trivial endeavor. But, not non-trivial in the impossible sense. The problem is you don’t know precisely what features will provide enough value to attract new customers until you’ve done some work.

I’ve generally found that if someone inside an ISV is asking if a feature is possible, it’s only a feature they want if it comes for free. They haven't done the homework to understand how the feature would work to provide value for the mainstream customer, and the idea is still in an incubation phase. It will be difficult to even estimate the amount of work required.

When they turn the question into:

What does it take to get this into our software?

Then you know they are serious and passionate about the idea, and it’s time to start talking.

Iterating on an ASP.NET MVC Model Binder

scott — Wed, 06 May 2009 01:49:00 GMT

After my last post on model binding tips I’ve had a number of questions about the nuances of model binding. Let’s work through a sample.

Imagine you have a Recipe class that can hold all the information you need to make Love Mussels, and now you've decided to build a model binder to bind and validate recipes.

Iteration 1

Let’s start with the naive approach. This code has a number of problems.

public class RecipeModelBinder : IModelBinder
{
    public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        var form = controllerContext.HttpContext.Request.Form;

        var recipe = new Recipe();            
        recipe.Name = form["Name"];
        // ... and so on for all properties

        if (String.IsNullOrEmpty(recipe.Name))
        {
            bindingContext.ModelState.AddModelError("Name", "...");
        }

        return recipe;
    }
}

Problem

The code works directly off the HttpContext.Request.Form.

There are a couple difficulties working with the Form collection directly. One problem is how your tests will require more setup to create an HttpContext, Request, and Form objects.

The second problem is related to culture. Values you need from the Form collection are culture sensitive because the user will type a date and time value into their browser using a local convention. However, the URL is another place you might need to check when binding values (the query string and routing data in general), and these values are culture invariant.

Instead of worrying about all these details, it’s better to use the ValueProvider given to us by the incoming binding context. The value provider is easy to populate in a unit test, and takes care of culture sensitive conversions.

Iteration 2

We’ll add a GetValue method to help fetch values from the ValueProvider. At runtime the MVC framework populates the provider with values it finds in the request’s form, route, and query string collections.

public class RecipeModelBinder : IModelBinder
{
    public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        var recipe = new Recipe();
        recipe.Name = GetValue<string>(bindingContext, "Name");
        // ... and so on for all properties

        if (String.IsNullOrEmpty(recipe.Name))
        {
            bindingContext.ModelState.AddModelError("Name", "...");
        }

        return recipe;
    }

    private T GetValue<T>(ModelBindingContext bindingContext, string key) 
    {
        ValueProviderResult valueResult;
        bindingContext.ValueProvider.TryGetValue(key, out valueResult);            
        return (T)valueResult.ConvertTo(typeof(T));
    }  
}

Problem:

If you use any HTML Helpers (like Html.TextBox), you’ll see null reference exceptions when validation errors are present.

One of the side-effects of model binding is that binding the model should put model values into ModelState. When an HTML helper sees there is a ModelState error for “Name”, it assumes it will also find the “attempted value” that the user entered. The helper uses attempted values to repopulate inputs and allow the user to fix any errors.

Iteration 3

The only change is to set the model value inside GetValue.

private T GetValue<T>(ModelBindingContext bindingContext, string key)
{
    ValueProviderResult valueResult;
    bindingContext.ValueProvider.TryGetValue(key, out valueResult);
    bindingContext.ModelState.SetModelValue(key, valueResult);       
    return (T)valueResult.ConvertTo(typeof(T));
}

Problem:

The model binder we’ve written so far will work with controller actions like the following:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(Recipe newRecipe)
{
    // ...
    return View(newRecipe);
}

But it won’t work in this scenario:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(FormCollection formCollection)
{
    var recipe = RecipeFactory.Create();
    TryUpdateModel(recipe);
    if (ModelState.IsValid)
    {
        // save it ...
    }
    return View(recipe);
}

The recipe in the controller action will never see any changes when calling TryUpdateModel, because the model binder is creating and binding data into its own recipe object. Perhaps you never use UpdateModel or TryUpdateModel, but if you expect your model binder to work in any possible situation, you need to make sure the model binder works when someone else creates the model.

Iteration 4

The only change is to check bindingContext.Model to see if we already have a model. Only when this property is null will we go to the trouble of creating a new model.

public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
{
    var form = controllerContext.HttpContext.Request.Form;

    var recipe = (Recipe)(bindingContext.Model ?? new Recipe());
    recipe.Name = GetValue<string>(bindingContext, "Name");
    
    // ... 

    return recipe;
}

Problem:

Congratulations! We just re-implemented the behavior of the DefaultModelBinder - only our model binder is stupid and only works with Recipes.

If all we need is validation for a specific type of model, we can derive from the built-in binder and override OnModelUpdated or OnPropertyValidating and provide our custom logic.

Iteration 5

OnModelUpdated is easy to work with, so what follows is the entire listing for our custom model binder.

public class RecipeModelBinder : DefaultModelBinder 
{
    protected override void OnModelUpdated(ControllerContext controllerContext,
                                           ModelBindingContext bindingContext)
    {
        var recipe = bindingContext.Model as Recipe;
        if (String.IsNullOrEmpty(recipe.Name))
        {
            bindingContext.ModelState.AddModelError("Name", "...");
        }
    }
}

It turns out we didn’t need any code from those first four iterations, but I hope you find them useful because they demonstrate some common problems I’m seeing in custom model binders. Of course we could take this example even further and eliminate the magic strings, but we’ll leave the work for another day.

In software development – every iteration is a learning opportunity!

6 Tips for ASP.NET MVC Model Binding

scott — Mon, 27 Apr 2009 07:12:00 GMT

Model binding in the ASP.NET MVC framework is simple. Your action methods need data, and the incoming HTTP request carries the data you need. The catch is that the data is embedded into POST-ed form values, and possibly the URL itself. Enter the DefaultModelBinder, which can magically convert form values and route data into objects. Model binders allow your controller code to remain cleanly separated from the dirtiness of interrogating the request and its associated environment.

Here are some tips on how to take advantage of model binding in your MVC projects.

Tip #1: Prefer Binding Over Request.Form

If you are writing your actions like this ..

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create()
{
    Recipe recipe = new Recipe();
    recipe.Name = Request.Form["Name"];
    
    // ...
    
    return View();
}

.. then you are doing it all wrong. The model binder can save you from using the Request and HttpContext properties – those properties make the action harder to read and harder to test. One step up would be to use a FormCollection parameter instead:

public ActionResult Create(FormCollection values)
{
    Recipe recipe = new Recipe();
    recipe.Name = values["Name"];      
            
    // ...
            
    return View();
}

With the FormCollection you don’t have to dig into the Request object, and sometimes you need this low level of control. But, if all of your data is in Request.Form, route data, or the URL query string, then you can let model binding work its magic:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(Recipe newRecipe)
{            
    // ...
    
    return View();
}

In this example, the model binder will create your newRecipe object and populate it with data it finds in the request (by matching up data with the recipe’s property names). It’s pure auto-magic. There are many ways to customize the binding process with “white lists”, “black lists”, prefixes, and marker interfaces. For more control over when the binding takes place you can use the UpdateModel and TryUpdateModel methods. Just beware of unintentional binding – see Justin Etheredge’s Think Before You Bind.

Tip #2: Custom model binders

Model binding is also one of the extensibility points in the MVC framework. If you can’t use the default binding behavior you can provide your own model binders, and mix and match binders. To implement a custom model binder you need to implement the IModelBinder interface. There is only method involved - how hard can it be?

public interface IModelBinder
{
    object BindModel(ControllerContext controllerContext, 
                     ModelBindingContext bindingContext);
}

Once you get neck deep into model binding, however, you’ll discover that the simple IModelBinder interface doesn’t fully describe all the implicit contracts and side-effects inside the framework. If you take a step back and look at the bigger picture you’ll see that model binding is but one move in a carefully orchestrated dance between the model binder, the ModelState, and the HtmlHelpers. You can pick up on some of these implicit behaviors by reading the unit tests for the default model binder.

Scott Hanselman demonstrates a non-trivial model binder in his post “Splitting DateTime – Unit Testing ASP.NET MVC Custom Model Binders”. One detail I want to call out about Scott’s DateTime splitter is how you still don’t need to use Request.Form when building the model. Inside the GetA<T> method you’ll see how Scott uses the binding context’s ValueProvider property to fetch data. The ValueProvider represents an amalgamation of all data from the request’s posted form values, routing data, and query string. Scott’s example is great, but it is missing one detail – the propagation of binding errors.

If the default model binder has problems putting data into your object, it will place the error messages and the erroneous data value into ModelState. You can check ModelState.IsValid to see if binding problems are present, and use ModelState.AddModelError to inject your own error messages. See this very simple tutorial for more information on how ModelState and HtmlHelpers can work together to present validation errors to the user.

If you scroll down the comments to Scott’s post you’ll see Sebastien Crocquesel’s patch for Scott’s code. If a conversion fails, Sebastien’s code will use ModelState.AddModelError to propagate the error. Both the controller action and the view can look in ModelState to see if there was a binding problem. The controller would need to check ModelState for errors before saving stuff into the database, while the view can check ModelState for errors to give the user validation feedback. One important note is that the HtmlHelpers you use in a view will require ModelState to hold both a value (via ModelState.SetModelValue) and the error (via AddModelError) or you’ll have runtime errors (null reference exceptions). The following code can demonstrate the problem:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(FormCollection Form)
{
    // this is the wrong approach ...
    if (Form["Name"].Trim().Length == 0)
        ModelState.AddModelError("Name", "Name is required");

    return View();
}

The above code creates a model error without ever setting a model value. It has other problems, too, but it will create exceptions if you render the following view.

<%= Html.TextBox("Name", Model.Name) %>

Even though you’ve specified Model.Name as the value for the textbox, the textbox helper will see the model error and attempt to display the “attempted value” that the user tried to put in the model. If you didn’t set the model value in model state you’ll see a null reference exception.

Tip #3: Custom Model Binding via Inheritance

If you’ve decided to implement a custom model binder, you might be able to cut down on the amount of work required by inheriting from DefaultModelBinder and adding some custom logic. In fact, this should be your default plan until you are certain you can’t subclass the default binder to achieve the functionality you need. For example, suppose you just want to have some control over the creation of your model object. The DefaultModelBinder will create object’s using Activator.CreateInstance and the model’s default constructor. If you don’t have a default constructor for your model, you can subclass the DefaultModelBinder and override the CreateModel method.

Jimmy Bogard has an example of sub classing the DefaultModelBinder in his post titled “A Better Model Binder”.

Tip #4: Using Data Annotations for Validation

Brad Wilson explains everything beautifully in this post: DataAnnotations and ASP.NET MVC.

I encourage you to go read Brad’s post, but if you are in a hurry, here is a summary:

.NET 3.5 SP1 shipped a System.ComponentModel.DataAnnotations assembly that looks to play a central role as we move forward with the .NET framework. By using data annotations and the DataAnnotationsModelBinder, you can take care of most of your server-side validation by simply decorating your model with attributes.

public class Recipe
{
    [Required(ErrorMessage="We need a name for this dish.")]
    [RegularExpression("^Bacon")] 
    public string Name { get; set; }

    // ...
}

The DataAnnotationsModelBinder is also a great sample to read and understand how to effectively subclass the default model binder.

Tip #5 : Recognize Binding and Validation As Two Phases

Binding is about taking data from the environment and shoving it into the model, while validation is checking the model to make sure it meets our expectations. These are different different operations, but model binding tends to blur the distinction. If you want to perform validation and binding together in a model binder, you can – it’s exactly what the DataAnnotationsModelBinder will do. You can also find samples like Automatic Model Validation with ASP.NET MVC, xVal, Castle, and a Custom Binder (John McDowall), and Enterprise Library Validation Application Block with MVC Binders (Steve Michelotti). However, one thing that is often overlooked is how the DefaultModelBinder itself separates the binding and validation phases. If all you need is simple property validation, then all you need to do is override the OnPropertyValidating method of the DefaultModelBinder.

Tip #6: Binders Are About The Environment

Earlier I said that “model binders allow your controller code to remain cleanly separated from the dirtiness of interrogating the request and its associated environment”. Generally, when we think of binder we think of moving data from the routing data and posted form values into the model. However, there is no restriction of where you find data for your model. The context of a web request is rich with information about the client. A good example is another Scott Hanselman post on automatically binding the user’s identity into a model see: IPrincipal (User) ModelBinder in ASP.NET MVC for easier testing.

In Conclusion

Model binding is beautiful magic, so take advantage of the built-in magic when you can. I think the topic of model binding could use it’s own dedicated web site. It would be a very boring web site with lots of boring code, but model binding has many subtleties. For instance, we never even got to the topic of culture in this post.

Do you have any model binding tips?

Life and Times of an ASP.NET MVC Controller

scott — Thu, 23 Apr 2009 05:44:00 GMT

The May issue of MSDN Magazine is now on-line with my article “The Life and Times of an ASP.NET MVC Controller”.

In this article, I will dissect the ASP.NET MVC framework and look at how controllers work. I'll explain how the framework interacts with your controllers and how you can influence those interactions. I'll look at controller factories, controller actions, action filters, and action results as well.

I don’t like programming by coincidence, and I hope this article gives you everything you need to work confidently with MVC controllers. In addition to the technical details, I also believe you have to properly apply a technology to make great software – thus the next installment of Extreme ASP.NET in July will cover some guiding principles to keep in mind when developing applications with the ASP.NET MVC framework.

Looking even further down the road (September seems so far away), I’m not sure what I’ll dig into next. Will it be web forms? More ASP.NET MVC? If there is something you want to hear about that is related to the ASP.NET server-side runtime - drop me a line or leave a comment.

ASP.NET MVC Controls and Good versus Evil

scott — Thu, 09 Apr 2009 07:53:00 GMT

Luis and David recently posted about the controls that appear in the ASP.NET MVC Futures 1.0 release.

Luis Abreu: The MVC framework: the Repeater control
David Hayden: ASP.NET MVC Controls in ASP.NET MVC Futures - Repeater Control Example

I’ve seen some discussions where people positively erupt at any mention of the word “control” in an MVC setting. These are the people who consider ASP.NET Web Forms as the ultimate source of evil in the universe – a cross between a Sith lord and a velociraptor. The idea of introducing controls, with un-testable event handling code and giant gobs of view state, is a travesty that will corrupt the minds of all developers before devouring their children. They must be stopped.

The Case For Controls

Let’s take the simple scenario of rendering a text input in the browser. If you are using the ASP.NET MVC framework release with no additional libraries, you’ll be looking to use one of the 4 Html helper TextBox methods (excerpted for space below):

string TextBox(... string name);
string TextBox(... string name, object value);
string TextBox(... string name, object value, IDictionary<string, object> htmlAttributes);
string TextBox(... string name, object value, object htmlAttributes);

A text input is a pretty trivial control, but even these 4 options don’t give you a clean path to the entire universe of things you might want to do when displaying a value in a text input, like specifying a formatting string to use when converting the model value to a string. One solution is to write additional helper methods, or include an additional library with the methods already written, but you are only adding to the number of method overloads a developer has to parse when they just want to display a simple text input. In the end, you’ll still be looking at code similar to the following…

<%= Html.TextBox("ReleaseDate",
                 String.Format("{0:d}", Model.ReleaseDate),
                 new { @class = "special" })%>

…versus the declarative syntax of the MVC futures TextBox control…

<mvc:TextBox Name="ReleaseDate" Format="{0:d}"
             class="special" runat="server" />

Note that the MVC control does not inject view state into the rendered output, but that’s not to say that the MVC controls don’t have some issues. One issue is that they still inherit properties, behaviors, and events from System.Web.UI.Control, and some of those inherited features don’t make sense in an MVC view.

I think I'm still happier using Html helpers.

Here are some advantages I see to using controls:

The declarative model is easier to scan because the named properties are explicit, whereas with HtmlHelpers the order of the unnamed parameters is important.
It’s easier to add extensibility via additional properties instead of adding yet another extension method overload.
The logic for a custom control is encapsulated in a class, with all of the benefits of using a class, whereas the entry point for an HtmlHelper is just a method.
Controls would probably be the preferred way to work for designers (of the human variety).
Controls would probably open up more opportunities for vendors to ship functionality.

And the disadvantages:

They remove the benefit of strongly typing the model, which is a huge loss.
Someone under the influence of the dark side can wire up event handlers.
It’s possible to build controls that are too smart for their own good (or for the view’s good).
Nobody knows what HTML might appear when the control renders (which, to be fair, is also true of 3rd party Html helpers).

It’s also worth pointing out that there are other solutions, besides controls, to the often clumsy Html helpers. By sticking to view-specific models, conventions, and effective CSS with JavaScript, you can remove many of the concerns that the HtmlHelpers burden themselves with. Using a view engine other than the web forms view engine can also solve some of these issues.

What do you think?

Will MVC controls be the spawn of Satan, or the blessing of a saint?

MVC Course is Coming Online!

scott — Tue, 07 Apr 2009 18:10:00 GMT

Just a quick note to let you know that the first three modules of my ASP.NET MVC course are ready for consumption at Pluralsight! On-Demand. Pluralsight is building a fantastic library of online content you can view as a subscriber, or see in person via instructor led training at a classroom or on-site at your place.

There is also a heap of free screencasts and previews to wet your appetite.

A single subscription can get you access to training for WPF, C#, .NET, ASP.NET, AJAX, WF, WCF, Silverlight, BizTalk, with more on the way.

P.S. I’ve heard the LINQ class is awesome, too…

Putting the M in MVC – Part III

scott — Mon, 06 Apr 2009 06:22:00 GMT

In the last post we talked about using entities as the models in an MVC application. This approach works well until an application reaches a certain level of complexity, at which point entities as the M in MVC can become painful.

I believe entities exist to serve the business layer. They also have a role in the data access layer, but only because the data access layer has to be acutely aware of entities. The reverse is not true – entities don’t need to know details about the data access layer nor how they are saved in persistent storage. Entities aren’t owned by the UI, or the data access layer. Entities are business objects and are owned by the business layer.

An application that supports a complex business needs a fine-tuned layer of business logic. You know an application is growing in complexity when you uncover scenarios like these:

Validation rules go beyond mere database constraints - maximum discount is 10% unless an administrator is overriding the discount percentage.
Multiple sets of validation policies are in effect - contracts signed in the state of Maryland after Jan 1, 2009 require additional checks to meet regional law #443570.
Entities are involved in long running business processes - the request for proposal requires approval from three directors before moving to a published state.
The application integrates with external applications and services - changes to any customer information must be published to the CRM system within 10 minutes.

These types of requirements have a significant impact on the design and behavior of the business layer and its entities. You want all this complicated business stuff in a layer where it is testable, maintainable, and free from the influence of all the infrastructure that surrounds it – databases, data grids, message queues, communication protocols, and the technology du jour. It’s a business layer built with business objects that encapsulate business state and business behavior. It’s the secret sauce that makes money for your company. It’s a rich model of your domain.

So - why wouldn’t we want to use this rich domain model inside of our views? Isn’t it every young view’s dream to grow up and marry an extraordinarily rich, fat model?

Models, Models Everywhere

Views can grow complex just as quickly as business logic can grow complex. Complex views might exhibit some of the following conditions.

Displays aggregate information from across the application (reporting views).
Displays information from disparate sources (composite views).
Lives on a different tier (the view is built using JavaScript, JSON, and client-side data binding).

Perhaps you don’t consider these views as super-complex because you build them all the time, but the types of views we are talking about in the above three bullet points do place requirements and constraints on the model. For example, the UI may require a model that can serialize into a JSON or RSS format.

If you share your entities or domain model with the UI layer, you’ll find your business objects have to serve two masters. The requirements from these two masters will pull your business objects in different directions, and they won’t be optimized to fit in either role.

Also, ask yourself these questions about the model for your views:

Who determines what properties the model should have?
Who invokes business logic on the the model?
Who owns the model?

Answers:

The view.
Not the view.
The view.

Complex applications often require multiple models. There is the domain model that encapsulates your company’s secret money-making business sauce, and then there are multiple view models that the UI layer consumes. Somewhere in between is logic that maps data between the various models. This isn’t a new idea, and it was at one time known as the Model Model View Controller pattern.

You might create a model class for each type of view, like a – MovieReviewViewModel, and perhaps all the UI models derive from a base class. The model classes will hold just the state that their respective views require. These classes don’t need behavior – they are essentially just data transfer objects. In a sense, the model classes also become contracts that explicitly describe what the controller needs to put together for the UI, and the view author sees a model with just the information they need.

Of course, building these additional models comes with a price.

You have to map data from the domain model into view model classes, and vice versa.
You have to figure out how to provide validation logic for view models.
You’ll write more code, and manage more classes.

It’s up to you to decide if the benefits are worth the price:

Your entities and business objects are optimized for business logic
Your view models are optimized for the UI
You achieve separation and isolation of the business and UI concerns

What Was The Original Question?

It was:

“I have created domain entities like Customer, Order, etc. They come out of repository classes backed by NHibernate. I’m wondering if I send them directly to the view or if I create a ViewModel class to hold data. I’m confused by all the terminology”.

I haven’t given a definitive answer, but I hope I’ve given you enough of my opinion to see that the answer depends on the complexity of your application and its long term goals. For forms-over-data applications, passing your entities can be a simple and effective solution. For more complex applications you may need models built specifically for your views to maintain the integrity and maintainability of your business objects.