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.

Express statement sub-elements of a function call by putting them into a closure in an argument.

You pass a delegate as a method parameter. The receiving method executes the function represented by that delegate against an object it controls.  Nested closure in C# is easy to spot because the delegate is usually typed as Action<T>, where T is the type of the object that the called method will provide as a parameter to our argument function.

The most obvious example is a common extension method:

public static void ForEach<T>(this IEnumerable<T> items, Action<T> action)
{
    foreach (T item in items)
    {
        action(item);
    }
}

Nested closure is like template method, but instead of deriving from a base class to affect behavior, the additional behavior is provided as an argument.  In the same way that template method is great when you want to communicate behavior from derivations to base classes, nested closure works when you want to communicate behavior as you call a method.

Consider working with a common series of steps when writing repository methods against NHibernate:

public Order[] GetAllOpenOrders(Customer customer)
{
    ISession session = GetSession();
    IQuery query = session.CreateQuery("from Order o where o.Resolution is null and o.Customer = ?");
    query.SetEntity(0, customer);
    var results = query.List<Order>().ToArray();
    return results;
}

Code like this – where you have the same basic structure in several methods – can be made more terse by using a nested closure.

public Order[] GetShippedOrders(Customer customer)
{
    const string hql = "select distinct s.Order from Shipment s where s.Order.Customer = ?";

    return Hql(hql, x => x.SetEntity(0, customer));
}

The second parameter is an Action<IQuery>.

protected T[] Hql(string query, Action<IQuery> additionalWork)
{
    IQuery iquery = GetSession().CreateQuery(query);

    if (additionalWork != null)
        additionalWork(iquery);

    return iquery.List<T>().ToArray();
}

Nested closures are also good for adding fluency to APIs.  This is the context of Fowler's writing, and you can see it clearly in Rhino Mocks:

repository.AssertWasCalled(x => x.Save(null), o =>
    {
        o.IgnoreArguments();
        o.Constraints(Property.AllPropertiesMatch(visitToSave));
    });

In this scenario we're passing a delegate that, when invoked later, helps Rhino Mocks configure options for its expectations.

• 9:00 AM Git for people by Joe Ocampo. 
  I just want to see someone fly through using this so I can upgrade my understanding from novice to .. post-novice. Hopefully some msysgit tricks for the Windows crowd. Can someone record this?
• 10:00 AM Eric Hexter's talk on Project Automation – Learn about Build and Deployment Automation
  Eric is a master on the subject and I'd love to glean some tidbits from his repertoire.
• 11:00 AM A Handful of Things You Can Do In Ruby That Scares the Pants Off of C# Developers by Scott Bellware
  I'm at least wary of dynamic languages (in the large), and I'm sure Scott will challenge my (mis)understandings.  Also hoping for a recording.
• 12:45 PM Enterprise Architecture Patterns: Presentation, Business Logic, and Persistence by Chad Myers and John Teague
  I will make it to this session, at least in part.. I know enough to know that there's so much I don't know.  This one will be all about information literacy.
• 2:45 PM Test Driven JavaScript by John Teague
  I hope John shows me a better way.. because mine is not frictionless.

The first is called Take It For A Test Drive – clearly a failed attempt at a witty name for a hands-on-keyboard workshop where participants will design and implement a new feature for CodeCampServer, an open source ASP.NET MVC project.  We'll get our hands on NHibernate, TDD, Rhino Mocks, Resharper.. and maybe some ASP.NET MVC (although I'm hoping that we touch the UI as little as possible since that stuff tends to slow workshops like this).

Here's the abstract:

Conception, design, tasking, testing, construction. We'll do it all by building a new feature into a .NET open source enterprise software application. We'll design as a team, test-drive the implementation, and use the tools that enable us to move fast. This is a hands-on, no holds barred opportunity to get down and dirty with TDD. Bring your laptop with required software installed: Visual Studio .NET 2008, TestDriven.NET, TortoiseSVN, Resharper 4.5, SQL Server 2005 Express with mixed mode authentication

It's really important that participants bring their laptops with all the software installed.  If you can build Code Camp Server locally and load the solution in Visual Studio, you're golden.  This isn't a presentation, it's a workshop.

So here's how it will go down:

• A 15-20 minute warm-up that involves checking out the source code and building it locally.
• I'll do a quick (very quick) rundown of the project and demo some Resharper stuff.
• I'll do another very quick intro to TDD if necessary.
• Then I'll present the specifications for the new feature and the participants will hash out the requirements with me as I role-play a product owner.
• As a team we'll use pseudo-UML and sequence diagrams to figure out exactly what we'll be doing and we'll task it out step by step.
• Then we'll go heads down and implement the feature.  I'll speak up and code on a projector at reasonable intervals.

It's a commitment to attend this one – you'll dedicate most of the morning to a workshop.  But if you are where I was a couple years ago – familiar with C# and most of the tools but needing help getting started with TDD and other techniques, I think you'll like this session.

In the afternoon I'll present my Practical IOC talk.  This one is a presentation.

Here's the abstract:

From the basics to interesting, more advanced usage scenarios, we'll discover how inversion of control can give life to object oriented principles and enable higher quality and faster delivery.

I'd say it's intermediate level subject matter.  I have modified it a little since I presented it last.  This one is a few (awesome!) slides and then me coding through usage scenarios.

Hope to see you there!

The problem was isolating authorization to view sections of a page.  In other words, if you didn't have permission X, you couldn't see the top-left section of the screen.  If you didn't have permission Y, you couldn't see top-right section of the screen.  By composing the controllers that decided how to display the sections, we could test drive nicely each controller's authorization check and subsequent decision.

Later we embraced the ViewModel concept and are working with strongly-typed views.  We found that using SubControllers wasn't the best approach in that situation, for a couple reasons:

First, that the view properly invokes the SubController remains untested.  The responsibility for performing the interaction still rests with the view.  So why not just make the authorization check in the view? 

That's the other problem: scattered partial views can be a small maintenance headache.  In our current project, after embracing the ViewModel, there just wasn't a pain that SubControllers cured.

We didn't abandon SubControllers because they didn't work, or because there was a flaw in the implementation, or because they were too complex, or anything like that.  They may still be the right approach for a given screen.

If you're unsure how to share view pieces in your application, refer to Jimmy's excellent guide.

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.

I tried to focus on the practices of using IOC tools, because there's a lot of abstract jibber-jabber about principles.  Don't get me wrong, I love the principles and the theory.  I just think talking about the practices creates a more powerful pedagogical vector through which a comprehension of the principles can "sneak" in.

If I do this talk again I'll scrap the open generics tidbit.  I think it's really neat, and that's why I included it.  But if one hasn't run into that pain, solving it isn't so cool, and it adds unnecessary complexity to the demonstration.  I'll have to come up with something better to replace it.

Here's an archive of the slides, notes and demo code.

And here's a thing, if you just want to browse a slightly mangled view of the slides: