I’ve made some tests before and after the switch and one video comparing Visual Studio load time with pretty heavy solution in it + ReSharper enabled:

As you see, VS load gets about 300% improvement. This is nice.

The CrystalDiskMark tests (notice the tremendous random IO difference):

WD Raptor 74GB 10000 RPM HDD (single one):

Crucial RealSSD C300 128G (SATA 3Gb/s mode):

Numbers speak for themselves.

In this part I’ll give a sample of designing view models for handling forms in MVC. Suppose that we need to create a controller and stuff around it to handle form like the following.

For the sake of demo simplicity I keep the form simple:

For this, we add View that specifies AccountRegisterViewModel as its model:

@model AccountRegisterViewModel
 
<h2>
    Register</h2>
 
@using (Html.BeginForm())
{
    @Html.ValidationSummary()
    <label>
        Name
        @Html.TextBoxFor(m => m.Form.Name)
    </label>
    <label>
        State
        @Html.DropDownListFor(m => m.Form.State, Model.StateSelectList)
    </label>
    <input type="submit" value="Register me" />
}

Then, we add a new view model class to ViewModels/Account directory. It contains all the data required to render the form, including drop down list data, and properties of the form to submit (in this sample we have a single form under Form property, but if you have multiple forms, then you can place each one under separate FormXXX property):

public class AccountRegisterViewModel : SharedLayoutViewModel
{
    public AccountRegisterForm Form { get; set; }
 
    public IEnumerable<SelectListItem> StateSelectList { get; set; }
}

We define a class that contains all the fields of our form. Later, we’ll be able to use strongly-typed helpers to render inputs. The class contains DataAnnotations attributes for form validation, and for other cases it can implement the IValidatableObject interface. So we have all the object level validation for the form in a single place. Nice and clean:

public class AccountRegisterForm
{
    [Required]
    public string Name { get; set; }
 
    [Required]
    public string State { get; set; }
}

The controller itself looks like this:

[HttpGet]
public ActionResult Register()
{
    var model = new AccountRegisterViewModel();
 
    SetupRegisterViewModel(model);
    return View(model);
}
 
[HttpPost]
public ActionResult Register([Bind(Include = "Form")]AccountRegisterViewModel model)
{
    if (ModelState.IsValid)
    {
        // save model.Form 
 
        TempData["Message"] = "Thank you for registering";
        return RedirectToAction("Index");
    }
 
    SetupRegisterViewModel(model);
    return View(model);
}
 
private void SetupRegisterViewModel(AccountRegisterViewModel model)
{
    model.StateSelectList = new SelectList(new[] { string.Empty, "NY", "VA" });
}

That’s it.

So, designing classes for your view models inevitably brings up some new concerns, like how should the Layout view models be implemented (master pages in terms of WebForms view engine).

From my experience, you should create an abstract class like SharedLayoutViewModel with all of the data properties required by your _Lauout.cshtml. Then, make all of the view models of views that use this layout inherit this class. You can use MVC Result filters to fill this model with data in a single place of your app, or, like I do, override the OnResultExecuting method in the common base class for your controllers, and fill it there.

To make your view models easy to find, organize them in a similar fashion as you do for views. I prefer putting all the view models in a single namespace (though in different project directories) and having full name as its class name like ProductsCreateViewModel (if you’re using ReSharper, set NamespaceProvider = False). This way I avoid need of explicit namespace reference in views and controllers. So my final layout looks like this:

In the next part I’ll give a sample of a simple form implemented using the described approach.

So. The bug.
I have a view with 1 dropdown generated from Model property and 3 additional dropdowns that are generated from array property.

@Html.DropDownListFor(m => m.AgentType, Model.AgentTypeListItems)
@for (int i = 0; i < Model.AgentTypes.Length; i++)
{
    @Html.DropDownListFor(m => m.AgentTypes[i], Model.AgentTypeListItems)
}

The controller method initializes AgentTypeListItems collection + sets default values for AgentType dropdown and 3 dropdowns for the collection:

var model = new OptionsViewModel();
 
// for DropDownListFor
model.AgentTypeListItems = new[]
{
    new SelectListItem { Text = "1", Value = "1" }, 
    new SelectListItem { Text = "2", Value = "2" },
    new SelectListItem { Text = "3", Value = "3" },
};
 
// 1 dropdown in the model
model.AgentType = "2";
 
// 3 dropdowns in array
model.AgentTypes = new[] { "3", "2", "1" };
 
return View(model);

The model class:

public class OptionsViewModel
{
    public SelectListItem[] AgentTypeListItems { get; set; }
    public string AgentType { get; set; }
    public string[] AgentTypes { get; set; }
}

When I open it in browser I get “2″ everywhere though AgentTypes array was initialized with different values(!):

When I replace DropDownListFor with TextBoxFor:

@Html.TextBoxFor(m => m.AgentTypes[i])

I get the correct values in the inputs (!):

this is how it should be

It means the TextBoxFor works as expected, but DropDownListFor doesn’t.
Will try to post the issue into MVC project bugtracker.

So, such “rapid” approaches can be attractive for the person, whose job is to create such video tutorials (probably trying to compete with the famous RoR one).

But in a real life applications, you’ll probably want to use strongly-typed models,  strongly-typed model-aware Html.TextBoxFor(m => ..) helpers for generating forms, and get strongly-typed POST data into controller method. In other words, you need acceptable maintainability for your projects in MVC.

So here are the rules to remember, if you’re going to develop with real MVC.

1. Views to ViewModels is a one-to-one relationship. Define separate ViewModel class for every single View.
2. View dictates ViewModel structure, not the controller.
3. ViewModles are dummy DTOs, with no logic in them.
4. Forget about calling Request.IsAuthenticated and similar in your views. ViewModel should contain ALL the data required to render the view.

In my next post I’ll describe how you can use  strongly-typed models in generic view layouts (master pages in MVC2). See Part 2.

Today, we have two ways to render partial and action stuff:

@Html.Partial("Details")
@Html.Action("Index", "Home")

and

@{ Html.RenderPartial("Details"); }
@{ Html.RenderAction("Index", "Home"); }

So what would you go with?

First approach looks cleaner, but I would use RenderPartial and RenderAction in most cases, just because these methods output their content into the same TextWriter object as used in the current template. In contrast to this, @Html.Partial and @Html.Action methods create their own TextWriter instances each time and buffer all their content into memory. In the final stage they just emit all writer content it into a plain MvcString object, so that it can be rendered as an unescaped HTML by the @ directive.

On the other side, I do not entirely through away @Html.Partial and @Html.Action. These methods are good for some cases when you need to put sub-template content into a variable or do something with it (which was a pain in older MVC versions). And they may be life-saving in certain scenarios like caching.

Oh, there is also a @RenderPage method of WebPageBase that doesn’t use MVC template lookup and receives exact template path as its parameter. But anyway I would use HtmlHelper’s Partial instead, as it is a more traditional view-engine independent approach for rendering child templates.

Suppose you have a checkout model that has two addresses – billing and shipping:

public class CheckoutInfoForm
{
    public CheckoutAddressForm BillingAddress { get; set; }
 
    public CheckoutAddressForm ShippingAddress { get; set; }
}

While each address has model like this:

public class CheckoutAddressForm
{
    public string FirstName { get; set; }
 
    public string LastName { get; set; }
 
    public string Address1 { get; set; }
 
    // and so on
}

How would you generate address fields for both and reuse the markup?

The correct answer is: use the @helper block. I know another good option (or even may be a better in this particular case) is using Edit template for such kind of things, but let’s assume that you selected @helper way for good some reason.

So here is the code of Razor view:

<form method="post">
<div>
    <h1>
        Billing Address</h1>
    @RenderAddressFor(t => t.Form.BillingAddress)
</div>
<div>
    <h1>
        Shipping Address</h1>
    @RenderAddressFor(t => t.Form.ShippingAddress)
</div>
<input type="submit" />
</form>
@helper RenderAddressFor(Expression<Func<CheckoutInfoViewModel, CheckoutAddressForm>> expr)
    {
        var convert = SubformUtil.GetConverter<CheckoutInfoViewModel, CheckoutAddressForm>(expr);
 
    <label>
        First Name
        @Html.TextBoxFor(convert(t => t.FirstName))
    </label>
    <label>
        Last Name
        @Html.TextBoxFor(convert(t => t.LastName))
    </label>
    <label>
        Address1
        @Html.TextBoxFor(convert(t => t.Address1))
    </label>
}

So far so good, but notice this little SubformUtil.GetConverter call. It is a simple shortcut creator function that I moved to a helper tool class:

using System;
using System.Linq.Expressions;
using LinqKit;
 
public static class SubformUtil
{
    public static Func<Expression<Func<TFormModel, string>>, Expression<Func<TViewModel, string>>>
        GetConverter<TViewModel, TFormModel>(Expression<Func<TViewModel, TFormModel>> expr)
    {
        return m => Linq.Expr((TViewModel vm) => m.Invoke(expr.Invoke(vm))).Expand().Expand();
    }
}

Also notice, that I’m using a wonderful LinqKit utility to generate the expression. That’s all. Hope this will be helpful.

You can use DELETED and INSERTED prefixes to refer inserted and deleted rows. But what if you want to insert rows in to a table and OUTPUT a field from the source table that you DO NOT insert into destination table (and thus the field is not available through the INSERTED prefix).

Assume the following scenario. You have a table variable where you want to put identifiers of the source and destination records (to use those later):

DECLARE @InsertedAnimals TABLE (AnimalID INT, @CatID INT);

And you want to execute a statement like the below to insert cats, where Cat is a table of CatID (identity), Name (varchar):

INSERT INTO Cat (Name) OUTPUT Animal.AnimalID, INSERTED.CatID INTO @InsertedAnimals
SELECT Name FROM Animal WHERE TYPE = 'Cat';

So that @InsertedAnimals would contain all the inserted AnimalID to CatID references. Obviously, this would not work, because you have no access to the Animal table in the OUTPUT clause. Only INSERTED prefix is available there.

BUT, there is a solution.

We can use the MERGE statement instead:

MERGE Cat AS t 
USING (SELECT Name FROM Items WHERE TYPE = 'Cat') AS s
ON 0 = 1 
WHEN NOT MATCHED BY TARGET THEN
  INSERT (Name) VALUES (Name)
OUTPUT s.AnimalID, INSERTED.CatID INTO @InsertedAnimals;

Easy, reliable and clean. A very nice alternative to using cursor, or locking tables and doing multiple requests and use ROW_NUMBER to determine inserted<—>original id references, etc.