Edit: Because this is my first day to ever work with EF, my first attempt at this was more complicated (you can see this evolution at the gist).  After removing my useless code, you can see it’s just Entity Framework.  Sadly I can’t take any credit.  Still – this IS cool.  Fast, super easy, typed queries with only framework dependencies.  I was surprised to see it supported the mapping-less projections.  Perfect for all of those fancy persistent view model scenarios all the cool CQRS kids are doing.

using System;
using System.Collections.Generic;
using System.Data.Entity;

public static class Effin
{
    public static IEnumerable<T> Query<T>
        (this string connectionStringName, string sql,
        params object[] parameters)
    {
        return new DbContext(connectionStringName)
            .Database.SqlQuery<T>(sql, parameters);
    }
}

public class Example
{
    public void UsingEffin()
    {
        IEnumerable<Name> names =
            "data".Query<Name>("select FirstName from Person");

        foreach (var name in names)
        {
            Console.WriteLine(name.FirstName);
        }
    }

    public class Name
    {
        public string FirstName { get; set; }
    }
}

True story: a team building a system.  They decide that one chunk of code might be valuable in another project or two.  So they extract it into a library and open source it.

Project complete, team reorganizes and begins a couple new projects.  Both new projects depend on that library.  For awhile everything is great.

Sooner or later someone needs to make a change.  It’s sort of a pain, because the source code is in another IDE configuration.  Actually it’s been awhile since anyone worked on it and it’s hard to find a developer on the team who has that version of the IDE installed.  But the change happens, painful as it may be, because it has to.

Someone later gets lazy.  They build it locally and copy the assemblies directly into the lib folder.  Now the library was compiled from source code that’s not in the version control system.  This is spinning out of control.  Or maybe that was intentional – because the other team is using the library too, but they have different needs and we’ve sort of been in a mutually-assured-destruction paralysis about what changes to make.

Eventually someone realizes the solution is not to depend on this library, the compiled bits, but to just copy the source code over.  We need to make our tweaks, they need to make their tweaks.  It makes sense.   So we lose our code reuse; does anyone care? 

This dirty-feeling code copying can be a good idea for a non-technical reason:  it emphasizes that the important element of reuse is the human expertise to understand, create, use and modify a solution that solves a particular problem.

Turns out NuGet is great for this.  I noticed that Rob Conery packaged his Massive library as just a file.  A source code file.  Not a .dll.  Great idea, and I immediately thought of all the code that I want to share among many projects but also have the flexibility to change, now – without context switching or fear of repercussions.

You just put the files in a Content subdirectory and the NuGet process will shove them in the project root or App_Code or wherever.

I did the same with a little utility class that we use a lot, and I’m going to do it some more. 

For many teams, a hosted NuGet feed with content files is the new helper library.

Typing is not the bottleneck.  Neither is typing.

If you’ve been a programmer sometime in the last fourteen billion years you’ve noticed that there’s this conversation about type systems, specifically about comparing static type systems to dynamic type systems.

Dynamic typing doesn’t mean you can change the type of a thing (even though you sometimes can) it means you can change the shape of types themselves at run time.  It means that you can tell a variable to write itself some new, strange, dynamic behavior, but you don’t tell it what to write, you tell it how to decide what to write.  And you can eliminate a lot of duplication this way.

But static type systems don’t give you that ability.  You have to define the shape and behavior of a type at compile time.

I know what you’re thinking: that really stinks!  I want the ability to muck about with my variables, and have them run my code against their own internals and have them write new methods for themselves, and decide how they handle calls against methods that don’t exist, and even crazier things.

The static type system folks can do something that’s really powerful.  They can use the type system itself as a global registry.

You see this in a lot of the C# written today, especially the stuff that makes heavy use of an IOC tool and generics.  They’ll ask the system to get all the types that implement some interface, or for the types that close some interface and another type.  Then they take these types and instantiate one instance of each of them, and use those instances in some way.  Each instance runs in a chain or pipeline, or to apply a series of filtering functions to a data set.

The type system becomes a big dispatch table, with type names as global keys, but it’s more like a dispatch tree, because of polymorphism and generic type parameters and all that.

It’s freakin’ cool, once you start doing it – it’s elegant and easy compared to the old stodgy way of programming.  And the IOC tools they use keep getting more interesting features that let them query the type-system-as-dispatch-tree in novel ways.

The dynamic type system folks will shrug and suggest implementing dispatch table with a hash like they’ve been doing in Perl for 15 years.

The static type system folks keep losing because their arguments are bad – Compile Time Checking and Tooling just aren’t cutting it.  But they may be onto something if they could articulate the benefits of this global registry better than I can.

When it fails later, it can tell us what we broke.  Failing tests alert us to regressions before we integrate.

A test is most valuable when it fails.

This is why the number-one-most-important rule of TDD is to maintain One Logical Assertion Per Test.  If you have more than one, a failing test becomes ambiguous.  This helps in writing the test and in understanding its failure, also known as diagnostics. 

When a test fails you should know exactly why.

After we’ve made it pass the first time, it becomes one in a suite of passing test cases we regularly run.   Now it can tell us what the system is doing in a way more understandable than the implementation code. 

A test is most valuable when it describes the behavior of the system rather than the implementation.

This is why the number-one-most-important rule of TDD is No Implementation Semantics.

Almost every time I’ve found myself struggling to deliver value with TDD it’s because I’ve failed to follow these two, coequal, number-one-most-important rules: One Logical Assertion Per Test and No Implementation Semantics

This selection is from chapter 19, Lightweight controllers.  All hyperlinks were added for this post.

A quick way to lighten the controller’s load is to simply remove responsibilities from it. Consider the burdened action, shown below:

A heavyweight controller

public RedirectToRouteResult Ship(int orderId)
{
   User user = _userSession.GetCurrentUser();
   Order order = _repository.GetById(orderId);

   if (order.IsAuthorized)
   {
      ShippingStatus status = _shippingService.Ship(order);

      if (!string.IsNullOrEmpty(user.EmailAddress))
      {
         Message message = _messageBuilder
            .BuildShippedMessage(order, user);

         _emailSender.Send(message);
      }

      if (status.Successful)
      {
         return RedirectToAction("Shipped", "Order", new {orderId});
      }
   }
   return RedirectToAction("NotShipped", "Order", new {orderId});
}

This action is doing a lot of work-it’s incomprehensible at first glance. You can almost count its jobs by the number of if statements. Beyond its appropriate role as director of the storyboard flow of the user interface, this action is deciding if the Order is appropriate for shipping and determining whether or not to send the User a notification email. Not only is it doing those things, but it’s deciding how to do them-it’s determining what it means for an Order to be appropriate for shipping and how the notification email should be sent.

Logic like this-domain logic, business logic-should generally not be in a user interface class like a controller. It violates the single responsibility principle, obfuscating both the true intention of the domain and the actual duties of the controller, which is redirecting to the proper action. Testing and maintaining an application written like this is difficult.

Cyclomatic complexity: source code viscosity

Cyclomatic complexity is a metric we can use to analyze the complexity of code. The more logical paths a method or function presents, the higher its cyclomatic complexity. In order to fully understand the implication of a particular procedure, each logical path must be evaluated. For example, each simple if statement presents two paths-one when the condition is true, and another when it’s false. Functions with high cyclomatic complexity are more difficult to test and to understand and have been correlated with increased defect rates.

A simple refactoring that can ease this is called Refactor Architecture by Tiers. It directs the software designer to move processing logic out of the presentation tier into the business tier.

After we move the logic for shipping an order to an OrderShippingService, our action is much simpler.

A simpler action after refactoring architecture by tiers

public RedirectToRouteResult Ship(int orderId)
{
   var status = _orderShippingService.Ship(orderId);
   if (status.Successful)
   {
      return RedirectToAction("Shipped", "Order", new {orderId});
   }
   return RedirectToAction("NotShipped", "Order", new {orderId});
}

Everything having to do with shipping the order and sending the notification has been moved out of the controller into a new class. The controller is left with the single responsibility of deciding where to redirect the client. The new class can fetch the Order, get the User, and do all the rest.

But the result of the refactoring is more than just a move. It’s a semantic break that puts the onus of managing these tasks in the right place. This change has resulted in a clean abstraction that our controller can use to represent what it was doing before. Other logical endpoints can reuse the OrderShippingService, such as other controllers or services that participate in the order shipping process. This new abstraction is clear, and it can change internally without affecting the presentation duties of the controller.

Refactoring doesn’t get much simpler than this, but a simple change can result in significantly lower cyclomatic complexity and can ease the testing effort and maintenance burden associated with a complex controller.

JSON (pronounced like the English name, Jason) hijacking is a rare hack similar to XSRF, except it’s targeted to request secure JSON from vulnerable applications. The JSON hijacking process involves several steps:

1. A conspiring site, via JavaScript, instructs the victim’s browser to request some secure JSON data from another site.

2. The evil JavaScript receives the JSON data.

3. If the JSON is formatted as an array, the evil script can exploit browser JavaScript processing code to read the JSON data and transmit it back to the attacking site.

Allow JSON via POST only

The solution to this exploit offered by ASP.NET MVC 2 is to only accept requests for JSON data by HTTP POST requests, rather than by GETs. This is baked into and enforced by the standard JsonResult action result that ships with the framework. If we were to request data to be returned by JsonResult with a GET request, we wouldn’t receive the JSON data.

Listing 11.12 shows how we must issue a POST from JavaScript code requesting JSON data.

Listing 11.12 Requesting JSON data via POST

<script type="text/javascript">
    $.postJSON = function(url, data, callback) {
        $.post(url, data, callback, "json");
    };

    $(function() {
    $.postJSON('/post/getsecurejsonpost',
        function(data) {
            var options = '';
            for (var i = 0; i < data.length; i++) {
                options += '<option value="' +  #|2
                data[i].Id + '">' + data[i].Title +
                '</option>';
            }
            $('#securepost').html(options);

        });
    });
</script>

 <h2>Secure Json (Post)</h2>
  <div>
    <select id="securepost"/>
 </div>

Listing 11.12 uses the jQuery JavaScript library to craft a special POST request for our JSON data.  When the results are returned, the function populates the select list with them.

Override defaults for GET access

The problem with this approach isn’t technical-this works and it prevents JSON hijacking. But it’s a workaround that’s sometimes unnecessary and can interfere with systems developed using the REST architectural style.

If this approach causes problems, we have additional options. First, we can explicitly enable JSON requests from GETs with the code shown in listing 11.13.

Listing 11.13 Directing JsonResult to accept GETs

[HttpGet]
public JsonResult GetInsecureJson()
{
    object data = GetData();

    return Json(data, JsonRequestBehavior.AllowGet);
}

This will allow our action to respond to normal JSON GET requests. Finally, we can scrap JsonResult itself, instead using an action result to return only non-vulnerable, non-array formatted, JSON.

Modifying the JSON response

The code in listing 11.14 shows a special action result that wraps vulnerable JSON data in a variable, d.

Listing 11.14 Creating a SecureJsonResult encapsulates serialization logic

public class SecureJsonResult : ActionResult
{
    public string ContentType { get; set; }
    public Encoding ContentEncoding { get; set; }
    public object Data { get; set; }

    public override void ExecuteResult(ControllerContext context)
    {
         if (context == null)
         {
              throw new ArgumentNullException("context");
         }
         HttpResponseBase response = context.HttpContext.Response;
         if (!string.IsNullOrEmpty(ContentType))
         {
              response.ContentType = ContentType;
         }
         else
         {
              response.ContentType = "application/json";
         }
         if (ContentEncoding != null)
         {
              response.ContentEncoding = ContentEncoding;
         }
         if (Data != null)
         {
              var enumerable = Data as IEnumerable;
              if (enumerable != null)
              {
                    Data = new {d = enumerable};
              }
              var serializer = new JavaScriptSerializer();
              response.Write(serializer.Serialize(Data));
         }
    }
}

This action result encapsulates the tricky code to output the proper JSON, and it works well. The downside to this approach is that we must use this d variable in our JavaScript code. Listing 11.15 shows consuming the serialized data using jQuery.

Listing 11.15 Consuming SecureJsonResult with jQuery

$(function() {
$.getJSON('/post/getsecurejson',
    function(data) {
        var options = '';
        for (var i = 0; i < data.d.length; i++) {
            options += '<option value="' +
            data.d[i].Id + '">' + data.d[i].Title +
            '</option>';
        }
        $('#secure').html(options);
    });
});

Using this technique, we can still use GETs to retrieve our JSON data, but the JSON is secure because it’s never just an array-any arrays are wrapped in a d variable. We just must be sure to access values through the d variable.

This unconventional code can be confusing. We recommend using the default behavior of using HTTP POST requests to retrieve JSON data. If that becomes a problem, you can switch to this technique.

We have several spots in our ASP.NET MVC 2 app that need to serialize an object into a RouteValueDictionary so that, in a subsequent request, it can be inflated, resurrected by the model binding infrastructure.

We wrote extension method called ToHttpDictionary and we used it like this:

<%= Url.Action("index", "something", new RouteValueDictionary(Model.ToHttpDictionary())) %>

or like this:

RedirectToAction("index", new RouteValueDictionary(form.ToHttpDictionary()))

(and no, we do not use those raw helper method, we wrap them with a strong-typed, smarter one  = ) )

The goal is to transfer this example object, that we might accept as an action parameter:

var spec = new SearchSpecification
{
    FirstName = "John",
    LastName = "Doe"
};

Into the arguments for another request:

http://example.com/search?FirstName=John&LastName=Doe

That’s a lot easier than creating a form and a bunch of hidden fields just to store parameters for a GET request, or using that kludge anonymous type business.  It also makes working with RedirectResult extremely easy, skipping all the nasty TempData stuff you might be tempted to use.

At first we just needed some small, flat objects to be “un bound”, but then once we needed prefixes, the ability to skip properties, support for custom unbinders, and to handle arrays we decided to pull it into its own library and put it on CodePlex.

public static IDictionary<string, object> ToHttpDictionary<T>
    (this T model, params Expression<Func<T, object>>[] propertiesToSkip)
{
    SpecificValueUnbinderFactory.CustomUnbinders =
        () => new ISpecificValueUnbinder[]
        {
            new EnumerationValueUnbinder(),
            new PersistentObjectValueUnbinder()
        };

    return new Unbinder().Unbind(x => x.Source(model).SkipProperties(propertiesToSkip));
}

Custom value unbinders are the analog to custom model binders.  For example, I’ve seen model binders that take the Id of an Entity from the request and hydrate a full Entity object from persistence.  In that case we need an unbinder (sorry, I really can’t think of a better name for the concept) to serialize the Entity as the Id property.  That would look something like this:

public class PersistentObjectValueUnbinder : ISpecificValueUnbinder
{
    public string UnbindValue(object value)
    {
        return ((PersistentObject)value).Id.ToString();
    }

    public bool AppropriatelyUnbinds(object value)
    {
        return value is PersistentObject;
    }
}

And you’d plug it in to the factory function like in the above example.

It’s just a simple helper function, but the technique has been useful.

public interface IMessageFomatter
{
    string Format(string message);
}

Instead of doing all the work in the implementation of this interface, the message formatter will aggregate several distinct rules.  An inversion of control tool is configured to compose these rules and provide them to the formatter.

public class MessageFomatter : IMessageFomatter
{
    private readonly IFormatRule[] _rules;

    public MessageFomatter(IFormatRule[] rules)
    {
        _rules = rules;
    }

    public string Format(string message)
    {
        foreach (var action in _rules)
        {
            message = action.ApplyRule(message);
        }
        return message;
    }
}

In this way each rule can be small, testable, and have only one job.  I can add functionality to the formatting process without changing the formatter or any existing rule. 

public interface IFormatRule
{
    string ApplyRule(string text);
}

public class DisclaimerRule : IFormatRule
{
    public string ApplyRule(string text)
    {
        return text + "\nDisclaimer: This message will self-destruct";
    }
}

public class UppercaseRule : IFormatRule
{
    public string ApplyRule(string text)
    {
        return text.ToUpper();
    }
}

This technique is extremely powerful and we use it all over the place in our projects.

Recently we were building a search screen.  It has several text input boxes and select lists and radio button groups, you know, the standard enterprisey UI mess.  Anyway, that’s what it was and it’s a common feature in the apps I work on. I’ve seen the scenario over and over. But armed with the above technique and LINQ to NHibernate, we were able to craft a much more elegant solution than we had previously created.

First we have a type that represents the search query.  It could be implemented by the class that represents the user interface form or be built by the user interface layer.  It’s sent to a service that will perform the query.

public interface IProductSearchQuery
{
    decimal? Price { get; set; }
    int? PriceRange { get; set; }
    string Name { get; set; }
    ProductCategory Category { get; set; }
    // ...
}

public interface IProductRepository
{
    Product[] Search(IProductSearchQuery query);
    // ...
}

What we don’t want is a huge method that checks to see if a search criteria exists and then conditionally appends predicates to a database query.  That’s the old school way, and it’s a beast to test and to change.  Adding a user interface element, like a new text input field, would require us to change that big method by introducing repetitive and dangerous new code.

What we do want are small, isolated specifications that we can aggregate like the message formatter.

public interface IProductSearchFilter
{
    bool ShouldApply(IProductSearchQuery query);
    IQueryable<Product> Filter(IQueryable<Product> candidates, IProductSearchQuery query);
}

An example filter:

public class PriceRangeFilter : IProductSearchFilter
{
    public bool ShouldApply(IProductSearchQuery query)
    {
        return query.Price.HasValue && query.PriceRange.HasValue;
    }

    public IQueryable<Product> Filter(IQueryable<Product> candidates, IProductSearchQuery query)
    {
        return from product in candidates
               where product.Price <= (query.Price + query.PriceRange)
               && product.Price >= (query.Price - query.PriceRange)
               select product;
    }
}

You can test drive this thing.  It’s small and distinct.  And using LINQ to NHibernate you can combine several of them in a way that produces one select.

public class ProductRepository : IProductRepository
{
    private readonly ISession _session;
    private readonly IProductSearchFilter[] _filters;

    public ProductRepository(ISession session, IProductSearchFilter[] filters)
    {
        _session = session;
        _filters = filters;
    }

    public Product[] Search(IProductSearchQuery query)
    {
        var products = _session.Linq<Product>();
        return _filters
            .Where(x => x.ShouldApply(query))
            .Aggregate(products, (candidates, filter) =>
                filter.Filter(candidates, query)).ToArray();
    }

    // ...
}

One tricky spot for a lot of people is that Aggregate call.  It does the exact same thing as the foreach in the message formatter: passes the seed (products, in this case) through the filters aggregating the result.  The lambda parameter variable candidates is the result of the previous filter (or the seed for the first filter).  In other ecosystems besides .NET, Aggregate is called reduce.  You can see why – each filter reduces the candidates according to its specification.

When you think about it, an entire architecture could be a reduce. That would be really interesting.

Speaking of NerdDinner, Scott asked me to use it to create an AutoMapper example.

AutoMapper, the brainchild of Jimmy Bogard, is an object-to-object mapper.  What that means is up to you – but we’ll use it here to map from the domain model to a view model.  The view model is an object heirarchy that represents the screen.  It’s as dumb as possible, just like the view.

We get a lot of nice things out of it and it helps us go faster.  You can read more about it AutoMapper from Jimmy or at the website on Codeplex.

For starters, NerdDinner isn’t the best scenario in which to apply AutoMapper.  NerdDinner is very small so there’s not much reuse to harvest. For example, if you format dates the same way a million times you can use AutoMapper to only write that formatting code once.  In a small application you may format dates two ways and only use the resulting text in two views.  It doesn’t make a lot of sense to extract a class just for that – it will seem like a lot of overhead. 

Also NerdDinner doesn’t have a rich domain model – there’s just not that much to do.  So the AutoMapper feature of flattening complex hierarchies can’t be appreciated.

I posted the result of this quick and dirty spike as a sample project – hopefully this will help you get started looking at it.

First, I copypasted a class to bootstrap AutoMapper:

namespace NerdDinner.Helpers.AutoMapper
{
    public class AutoMapperConfiguration
    {
        public static void Configure()
        {
            Mapper.Initialize(x => x.AddProfile<ViewModelProfile>());
        }
    }
}

.. which will be called when the application starts:

void Application_Start()
{
    AutoMapperConfiguration.Configure();

    RegisterRoutes(RouteTable.Routes);

    ViewEngines.Engines.Clear();
    ViewEngines.Engines.Add(new MobileCapableWebFormViewEngine());
}

I copypasted another class that will check the mapping configuration for errors, providing fast feedback should I make a mistake.

[TestClass]
public class AutoMapperConfigurationTester
{
    [TestMethod]
    public void Should_map_dtos()
    {
        AutoMapperConfiguration.Configure();
        Mapper.AssertConfigurationIsValid();
    }
}

Now I’m ready to begin creating the view model and configuring AutoMapper.

To design a view model, start with the screen.  What’s displayed will be represented in the model.  Again: the view model is an object hierarchy that represents the user interface.  I picked the Dinner Details screen, by the way.

The current model being used by the view was the Dinner entity itself.  There was a lot of formatting in the view and a lot of duplication.

Almost every property was surrounded by code that would HtmlEncode it (it will be nice to have AutoMapper do this for us):

<%= Html.Encode(Model.Title) %>

And there is a lot of formatting to do:

<abbr class="dtstart" title="<%= Model.EventDate.ToString("s") %>">
    <%= Model.EventDate.ToString("MMM dd, yyyy") %>
    <strong>@</strong>
    <%= Model.EventDate.ToShortTimeString() %>
</abbr>

Imagine a project with 300 screens and a team of analysts and you can imagine that specifying this formatting over and over again in requirements documents and planning would become tedious.  Not to mention coding it.  It’d be easier to just say: “Format this date in the standard way.” You can also imagine the security implications of forgetting to encode even one value.

In converting these screens to use a view model instead of the domain model I didn’t want to change existing functionality.  So I took this:

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage<NerdDinner.Models.Dinner>"

and changed it to this:

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage<DinnerDetailsViewModel>"

See what I did there?  I just changed the type of the Model property to a new DinnerDetailsViewModel type.

The view will receive a view model mapped from the domain model when I apply a special action filter to the controller action:

[AutoMap(typeof(Dinner), typeof(DinnerDetailsViewModel))]

The code’s in the sample, straight from Jimmy’s post.

I started out with DinnerDetailsViewModel being an empty class definition and used Resharper to generate each property as I encountered it.  I removed the formatting and the ubiquitous encoding from the parameters, turning this:

<div id="dinnerDiv" class="vevent">

    <h2 class="summary"><%= Html.Encode(Model.Title) %></h2>

    <p>
        <a href="http://feeds.technorati.com/events/<%= Url.AbsoluteAction("Details", new { id = Model.DinnerID }) %>">
            Add event to your calendar (iCal)
        </a>
    </p>

    <p>
        <strong>When:</strong>
<abbr class="dtstart" title="<%= Model.EventDate.ToString("s") %>">
<%= Model.EventDate.ToString("MMM dd, yyyy") %>
<strong>@</strong>
<%= Model.EventDate.ToShortTimeString() %>
</abbr>

into this:

<h2 class="summary"><%= Model.Title %></h2>

<p>
    <a href="http://feeds.technorati.com/events/<%= Url.AbsoluteAction("Details", new { id = Model.DinnerID }) %>">
        Add event to your calendar (iCal)
    </a>
</p>

<p>
    <strong>When:</strong>
    <%= Model.EventDate %>
</p>

I had to write a formatter to replace the custom formatting performed by the view.

public class AttendeeNameFormatter : BaseFormatter<string>
{
    protected override string FormatValueCore(string value)
    {
        return value.Replace("@", " at ");
    }
}

See how testable that is; small and reusable?

I also moved some methods that were previously being called from the view directly into the domain model which AutoMapper will evaluate at runtime.

Before:

<p id="whoscoming">
    <strong>Who's Coming:</strong>
    <%if (Model.RSVPs.Count == 0){%>
          No one has registered.
    <% } %>
</p>

After:

<p id="whoscoming">
    <strong>Who's Coming:</strong>
    <%if (Model.IsNobodyRegistered){%>
          No one has registered.
    <% } %>
</p>

The view model for this screen ends up looking like this:

public class DinnerDetailsViewModel
{
    public string Address { get; set; }
    public string Title { get; set; }
    public string DinnerID { get; set; }
    public string EventDate { get; set; }
    public string Country { get; set; }
    public string Latitude { get; set; }
    public string Longitude { get; set; }
    public string Description { get; set; }
    public string HostedBy { get; set; }
    public string ContactPhone { get; set; }
    public bool IsAnyoneRegistered { get; set; }
    public bool IsNobodyRegistered { get; set; }
    public bool IsCurrentUserRegistered { get; set; }
    public bool IsCurrentUserHosting { get; set; }

    public List<RsvpViewModel> RSVPs { get; set; }

    public class RsvpViewModel
    {
        public string AttendeeName { get; set; }
    }
}

The really key part is the AutoMapper configuration profile.  You can group configurations with profiles.  Maybe in one profile you format dates in one way, in another profile you format dates in another way.  I’m just using one profile here.

public class ViewModelProfile : Profile
{
    protected override string ProfileName
    {
        get { return "ViewModel"; }
    }

    protected override void Configure()
    {
        AddFormatter<HtmlEncoderFormatter>();
        ForSourceType<DateTime>().AddFormatter<StandardDateFormatter>();

        CreateMap<Dinner, DinnerDetailsViewModel>()
            .ForMember(x => x.IsCurrentUserRegistered, o => o.ResolveUsing<CurrentUserRegisteredResolver>())
            .ForMember(x => x.IsCurrentUserHosting, o => o.ResolveUsing<CurrentUserHostingResolver>())
            .ForMember(x => x.EventDate, o => o.SkipFormatter<HtmlEncoderFormatter>());

        CreateMap<RSVP, DinnerDetailsViewModel.RsvpViewModel>()
            .ForMember(x => x.AttendeeName, o => o.AddFormatter<AttendeeNameFormatter>());
    }
}

Most properties of the view model are mapped conventionally.  The property names match up so AutoMapper knows exactly what do do with them.  AutoMapper will do a lot more for you if you’d like it to.  This is actually a pretty hefty configuration.  In a different scenario it’d be likely that almost everything is mapped conventionally.

Note the first AddFormatter call.  That’s instructing AutoMapper to html encode everything.  I skip it for a property later.  The possibilities here are endless.  One cool thing we do in another project is wrap each property in a span that’s given a conventionally named CSS class.  In automated UI tests, we can use that class to find the proper element and ensure that the screen is displaying the right thing.

Let me know if you have any questions.

If it’s not clear how to model a particular element in your model, try asking “which one?” If the question makes sense within your own scenario then you’re probably dealing with entities. If the question “which one” is meaningless in the context of your domain then you’re probably better off modeling the subject of the question as a value object.

I suggest that if you’re maintaining a collection, you implicitly care which one.