Like many github users, I often create forks for projects whenever I want to pull down their code, rather than cloning from the source directly.  This is pretty much the default way of working on github, as the site encourages collaboration through individualized repositories.  On my github page, this is what you’d see for my repositories:

It’s front and center, right on my home page.  Only two of those repositories were ones that I created completely fresh, and the rest are forks.

The other day, I posted a question on the StructureMap mailing list, but wound up getting a response in a github pull request!

This is because it’s just as easy to fork a user’s repository as it is the central repository.  Even the concept of a “central repository” isn’t ingrained in git (or github), there are only “blessed” repositories that the OSS project’s organizers agree upon.  For example, the “blessed” AutoMapper repository is just the AutoMapper repository in my github.

Pretty sweet, I can pull in this request locally, as well as any upstream StructureMap changes (as Git allows me to have as many remotes as I want), and see if it works for me.  If it does, I can then issue a pull request to the blessed StructureMap repository.  But if it doesn’t go through, no worries, I have my own StructureMap repository :)

Comparison to CodePlex

CodePlex is fantastic for a public-facing project hub, but it’s still not close to github on the OSS collaboration side.  Here’s an example, my homepage for the AutoMapper repository looks like this:

I have a wealth of information at my disposal here.  For new users, it’s a one-click operation to watch the project, fork it, create a pull request.  I can see how many folks follow the project or forked it.  All the information here is about the repository itself, rather than a project.  Github has a separate page for that, but by default, it’s about collaboration rather than documentation.

On CodePlex, I get a list of checkins:

The list of forks isn’t that much better.  CodePlex is definitely making strides, but you can definitely tell the difference between an OSS project hosting site built around DVCS versus one around centralized version control.  In github, its design is built around distributed collaboration, centered around individual commiters.  In CodePlex, its design is built around centralized projects.

Both definitely have their benefits, as it’s super-easy to get a URL to the CodePlex AutoMapper project page:  http://automapper.codeplex.com.  In fact, I kept the project on CodePlex because its support for project-centric activities I felt was better.  However, its support for collaboration-centric workflows still is pretty far away from github.  Unfortunately, CodePlex has to support both centralized (TFS) and distributed (Hg) source control systems, so I’m not sure how it’ll all shake out in the end…

In the last post, we looked at a workflow very common in the Git sphere: utilizing local branches to create segregated workspaces for individual topic branches.  As far as I can tell, this seems to be the preferred day-to-day workflow for Git users, as its first-class local branching support makes it completely seamless to create segregated areas of work.

This workflow is completely possible in Hg, but does take little more set up and one or two extra steps that Git doesn’t force you to make.  The idea behind this workflow is that I can’t predict when unrelated work comes in.  Because local branches and local commits are so cheap, there’s really no reason to throw any code away, ever.  With local topic branches, I can keep mini-spikes around without affecting anyone.

However, there are scenarios where the likelihood of unrelated work is small, so the need for topic branches tends to diminish.  With Hg, the limitations of its model of local branches, bookmarks and rebasing tends to lessen the full benefits of local topic branches.

For those cases where I’m truly confident that I’m working on a continuous main line of work, I’ll use a slightly different workflow than one that uses topic branches.

The simplified workflow

In the simplified workflow, it is nearly identical to the normal centralized workflows (except most operations are local).  When I want to start work for the day, I’ll:

• work work work
• hg commit –Am “Working on some stuff”
• work work work
• hg ci –Am “Working on some more stuff”
• work work work
• hg ci –Am “Finished my stuff”

At this point, I’ve finished some logical set of work, and I’d like to push my work upstream.  My local repository now looks like:

Unlike the previous workflow, my “master” bookmark moves along, instead of always pointing at the latest pulled commit.  It’s still important that this bookmark sticks around, as we’ll see soon.  Now that I want to push, I want to first pull down incoming commits.  Let’s suppose that someone else also made some commits on another repository and already pushed.  The server repository shows this:

Note that we don’t see our bookmarks here, as by default bookmarks don’t get pushed upstream.  When we pull from upstream, we’ll get the commit from the “otherdude” developer.  So, I’ll:

• hg pull --rebase

Instead a “pull/merge/update” workflow, which generates noisy merge commits, I’ll rebase my three commits against the upstream changes.  Rebase simply replays my three commits against the incoming tip.  That would mean that I expect to see that the parent of “Working on some stuff” to be the “otherdude” commit instead of the “Finishing work on a feature” commit.  After the pull and rebase, my local repository is now:

This is what we expected, our commits that originally came after the “Finishing work on a feature” commit got moved AFTER the “otherdude” commit.  This produces a nice clean timeline that makes localizing bugs and merging changes a lot easier.  With a regular pull/merge workflow, you’re merging all 3 commits at once.  With a rebase, I merge one commit at a time, making the potential merges much smaller.  Each merge also modifies each commit, instead of one gigantic merge commit with all changes coming in at once.

Anyway, I’ve pull upstream changes, so now I’m ready to push:

• hg push –b master

I only want to push that mainline branch, “master”, just like my previous workflows.  By pushing only my “master” branch, I can transfer back and forth between my simplified, mainline workflow and topic branch workflow very easily, with neither conflicting with the other.  In Git, only the current branch is ever pushed by default, but in Hg, it’s the opposite, so I have to a bit more explicit.

Comparing rebase and merge

Just to show what a merge looks like in comparison, let’s say “otherdude” doesn’t rebase before he commits his additional work.  He has some more commits:

Now he wants to push these two commits up.  However, the other user already pushed rebased commits, so now the server looks like:

Instead of doing a rebase on pull, he does a regular pull and update.  Because other commits have gone in, he’ll need to do a merge:

• hg pull –u
• hg merge
• hg ci –Am “Stupid merge commit”

He tries to pull and update, but since there were commits there, two heads get created and he needs to merge in his changes.  This causes an extra merge AND commit step, and now uglies up the history:

So the silly thing about this is the stupid merge commit contains ALL changes from the other two outgoing commits, yet all three commits get pushed!  This also becomes really ugly over time, especially when you have overlapping commits and merges:

I’m not sure human beings are meant to comprehend this picture, so I’ll take the rebased workflow with its clean, linear history any day of the week.  With the simplified workflow, rebasing is actually simpler than the pull/merge/commit workflow.  Rebase is good, whether we work in topic branches or not.

Yesterday, I gave a talk at the virtual ASP.NET MVC conference, mvcConf on “Putting your controllers on a diet.  You can find the slides and code at the Headspring Labs CodePlex site:

http://headspringlabs.codeplex.com/

Just clone the Hg repository, and you’ll find all the code and slides.  In the talk, I showed how to incrementally refactor this:

public class ConferenceControllerBefore : DefaultController
{
    private readonly IConferenceRepository _repository;

    public ConferenceControllerBefore()
    {
        _repository = new ConferenceRepository(Sessions.Current);
    }

    public ActionResult Index(int? minSessions)
    {
        minSessions = minSessions ?? 0;

        var list = (from conf in _repository.Query()
                    where conf.SessionCount >= minSessions
                    select new ConferenceListModel
                    {
                        Id = conf.Id,
                        Name = conf.Name,
                        SessionCount = conf.SessionCount,
                        AttendeeCount = conf.AttendeeCount
                    }).ToArray();

        return View(list);
    }

    public ViewResult Show(string eventName)
    {
        var conf = _repository.GetByName(eventName);

        var model = new ConferenceShowModel
        {
            Name = conf.Name,
            Sessions = conf.GetSessions()
                .Select(s => new ConferenceShowModel.SessionModel
                {
                    Title = s.Title,
                    SpeakerFirstName = s.Speaker.FirstName,
                    SpeakerLastName = s.Speaker.LastName,
                }).ToArray()
        };

        return View(model);
    }

    public ActionResult Edit(string eventName)
    {
        var conf = _repository.GetByName(eventName);

        var model = new ConferenceEditModel
        {
            Id = conf.Id,
            Name = conf.Name,
            Attendees = conf.GetAttendees()
                .Select(a => new ConferenceEditModel.AttendeeEditModel
                {
                    Id = a.Id,
                    FirstName = a.FirstName,
                    LastName = a.LastName,
                    Email = a.Email,
                }).ToArray()
        };

        return View(model);
    }


    [HttpPost]
    public ActionResult Edit(ConferenceEditModel form)
    {
        if (!ModelState.IsValid)
        {
            return View(form);
        }

        var conf = _repository.GetById(form.Id);

        conf.ChangeName(form.Name);

        foreach (var attendeeEditModel in form.Attendees)
        {
            var attendee = conf.GetAttendee(attendeeEditModel.Id);

            attendee.ChangeName(attendeeEditModel.FirstName, attendeeEditModel.LastName);
            attendee.Email = attendeeEditModel.Email;
        }

        return this.RedirectToAction(c => c.Index(null), "Default");
    }
}

Into this:

public class ConferenceAfterController : DefaultController
{
    public ActionResult Index(int? minSessions)
    {
        return Query<ConferenceListModel[]>(View(new ListConferences(minSessions)));
    }

    public ActionResult Show(Conference eventName)
    {
        return AutoMapView<ConferenceShowModel>(View(eventName));
    }

    public ActionResult Edit(Conference eventname)
    {
        return AutoMapView<ConferenceEditModel>(View(eventname));
    }

    [HttpPost]
    public ActionResult Edit(ConferenceEditModel form)
    {
        var success = this.RedirectToAction(c => c.Index(null), "Default");
        
        return Form(form, success);
    }
}

The recordings for the talks will be posted soon, so stay tuned to the mvcConf website for details.  Thanks again to the organizers (Eric Hexter, Javier Lozano, Jon Galloway, and some others I know I’m forgetting).  The conference went more smoothly than a lot of non-virtual conferences I’ve been to, so hopefully we have another one soon (well, not TOO soon…)

The nice thing about distributed version control systems (DVCS) such as Git and Hg is that they both allow me to basically decide how my source control should fit with my short and long-term development workflows.  A while back, I wrote what was basically a stream of consciousness post on getting my Git workflow working in Hg.  Well, a teammate tried to follow those steps…and found that I missed a few important nuggets.

My local workflow revolves around local branches and rebasing.  There are plenty of good articles out there on why this is an interesting and valuable workflow to know and understand, so I won’t rehash all the arguments.  I will say that I like this workflow because it:

• Gives me a clean, linear, understandable timeline
• Allows me to keep lines of work separate from each other, until it’s ready to push back upstream
• Works well in the face of unpredictable work
• Is light, quick, and does not leak into the public, mainline work

I tried a few other options, such as real branches, patch queues, and so on, but none had the same flavor that I was looking for with local topic branches.  With local topic branches, I don’t use different commands for committing (as I would with patch queues), nor do my branches leak metadata into the public timeline, as it would with normal Hg branches.

First, let’s get our local environment set up appropriately.

Prepping our environment

The cornerstone of my local development workflow include the Rebase and Bookmarks extension.  To enable these extensions, just modify your hgrc file.  You’ll also want to enable tracking the current commit for bookmarks.  This ensures that our bookmark gets moved up with each commit, instead of getting just stuck on one.  Your hgrc file would now include:

[extensions]
rebase = 
bookmarks =

[bookmarks]
track.current = True

I’ve enabled the Rebase and Bookmarks extension, and configured bookmarks to track the current commit.  Tools like TortoiseHg have features that light up when bookmarks are enabled, so you’ll have all sorts of things help you in those tools.

Now that we have our extensions enabled, we need to create our local marker for a master branch.  This bookmark represents the last pushed commit, so you can execute the “outgoing” command to make sure that you have nothing to push:

If everything’s good, we’ll create the “master” bookmark:

Git will create a “master” branch by default when you clone, but we’ll need to do this manually.  You can think of “master” as trunk.  It represents the mainline of the code we’re working on, and everything will be pulled into this line, both from upstream and from our local branches.  Our repository explorer, as seen in TortoiseHg, now looks like:

Note here that “master” is orange.  This indicates that “master” is the current bookmark being tracked.  Now that we have our local repository set up, we can walk through making local changes.

Scenario 1: One local branch, no upstream changes

First, let’s create a local topic branch and make some changes:

• hg bookmark SomeTopic
• --work work work
• hg commit –Am “Simple Change”
• -- work work work
• hg commit –Am “Some other change”

At this point, we decide we want to push our changes up.  We first want to synchronize our local repository with upstream, but we want to do this on master.  So we:

• hg checkout master
• hg pull --rebase

We switch back to the master branch and synchronize with upstream.  But since there aren’t any upstream changes, we want to now fold our SomeTopic branch back to master.  Here’s what the picture looks like right now:

Since there are no other local branches, we follow a special workflow as Mercurial’s rebase extension does not do a fast-forward merge by default.  That is, if I tell Hg to rebase or merge SomeTopic, I really just want to move master up to SomeTopic, and not perform some merge.  So I:

• hg checkout SomeTopic
• hg bookmark -f master
• hg bookmark -d SomeTopic
• hg push -b master

I switch back to the SomeTopic branch, and move the master bookmark up to SomeTopic.  I could have done this with “hg bookmark –f master –r SomeTopic”, but I want to switch to SomeTopic instead.  I delete the SomeTopic bookmark, as “master” is now moved up to SomeTopic.  Finally, I push master, and ONLY master up.  I don’t want any other local topic branches to get pushed until they’re integrated with my mainline master branch.  When we’re finished, this is what our local repository looks like:

Scenario 2: Need to work on unrelated items but not push unfinished work

aka, the whole reason for topic branches.  In this case, we’ve created our local topic branch, but now some other work comes in that we need to do.  We need to work on something else unrelated to our feature work, and don’t want to push the feature work until it’s done.  Our local repository first starts out like this:

Just to review what we’re seeing here, the “master” bookmark points to the last pulled commit from upstream.  We’re currently on the TopicOne bookmark, indicated here because it’s orange.  The two up arrows indicate that I have not yet integrated and pushed my TopicOne branch.  You can also execute “hg bookmark” at the command line to view the bookmarks and your current tracked one:

So we’re working on TopicOne, which might represent some feature we’re working on.  Some other work comes up, maybe it’s to fix some CSS or a batch script that has a higher priority than this feature.  But we don’t want to push our TopicOne changes yet, it’s not ready to deploy, the tests are broken, it’s just not finished.  So, we’ll start a new topic by:

• hg checkout master
• hg bookmark TopicTwo

At this point we can start committing as need be:

• work work work
• hg ci –Am “Critical work”
• work work work
• hg ci –Am “More critical work”

Once we’ve done that first commit, Hg will tell you that a new head was created.  This is because we first switched back to master, created a new bookmark, and started committing.  Here’s what our repository looks like right now:

Again, master sits back as our last pulled commit.  It’s the critical placeholder that helps us know where to start new topic branches from.  It’s not required, as I could look at these arrows to know what the last pulled commit was to start from, but it’s a lot easier when doing rebases and merges.

Now that TopicTwo is finished, I want to integrate TopicTwo into master and push it back upstream.  Because master is a direct ancestor of TopicTwo, I only need to follow the Scenario #1 workflow:

• hg co master
• hg pull --rebase
• hg co TopicTwo
• hg bookmark –f master
• hg bookmark –d TopicTwo
• hg push –b master

It’s very important that I only push master, as that lets my local repository now look like:

Now that my critical work is done, I can go back to working on TopicOne:

• hg co TopicOne
• work work work
• hg ci –Am “Finishing work on a feature”

Once I do this, my local repository looks a little changed now:

Here we see the master branch hanging off to the side, and my un-pushed changes in the TopicOne timeline.  But now master is no longer in the ancestry of TopicOne.  Now that I want to integrate TopicOne into master, I can either merge this branch, or rebase it.  I prefer rebase, so I’ll follow the normal rebase workflow.  But first, whenever we’re about to push changes, we ALWAYS:

• hg co master
• hg pull --rebase

Now that we’re sure we have the latest and greatest, we can rebase our TopicOne onto master:

• hg co TopicOne
• hg rebase –b TopicOne –d master

We switch to the TopicOne branch, then rebase from the base of TopicOne to the destination of master.  This command replays the commits from TopicOne onto master, then deletes the TopicOne commits.  Because the timeline changes, these are entirely new commits with new hashes, but containing the exact same changes/commit messages/commit times:

Even though I committed two of my changes before the original TopicTwo branch, after a rebase, these commits show up after the TopicTwo.  This is because a rebase replays the commits one at a time on top of the destination (master).  At this point, I can run the build to make sure everything works, and then follow the normal workflow when master is a direct ancestor of my topic branch, skipping the steps of pulling (we already did that):

• hg bookmark –f master
• hg bookmark –d TopicOne
• hg push –b master

Finally, here’s what my repository looks like:

Because I’ve always rebased, no one ever needs to know about my topic branches until I integrate.  The pushed timeline is always a clean, linear progression for the mainline master branch (in this case, it’s “dev” as the actual Hg branch).  With topic branches, each topic is independent of each other, and I decide when that topic is ready to be integrated into the mainline.  I might never integrate back, and switching topic branches is a VERY VERY fast “hg checkout” command away.  This workflow is fast, cheap, flexible, and allows me to have one working directory and one repository that contains all the work I’m doing, no matter what its state.

When working with other people, it’s inevitable that file conflicts arise.  In the next post, I’ll dive in to how to deal with conflicts along each step of the way and how this workflow functions in a team environment.

In my recent adventures with massive bulk processing, there are some times when I want to pull bulk loaded tables from SQL, but don’t want to go through all the trouble of building a mapping in NHibernate.  For example, one recent project had an intermediate processing table of something like:

This table is used in a bulk copy scenario, so it’s very string-based to ease the burden of bulk loading.  Later, we’ll transactionally process this table to update our actual customer table.  In the meantime, we want to use this data in a .NET application.  We have a few options:

• Load into a DataSet
• Stream from an IDataReader
• Map using NHibernate
• Ad-hoc map using NHibernate

Many times, I like to go with the last option.  DataSets and data readers can be a pain to deal with, as most of the code I write has nothing to do with dealing with the data, but just getting it out in a sane format.

NHibernate supports transformers, which are used to transform the results of the query into something useful.  To make things easy, I’ll create a simple representation of this table:

public class BulkLoadCustomer
{
    public string CustomerId { get; set; }
    public string RegisteredDate { get; set; }
}

I’ll create some generic query:

var sql = "SELECT CustomerId, RegisteredDate FROM BulkLoad.Customer";

var sqlQuery = _unitOfWork.CurrentSession.CreateSQLQuery(sql);

I just have the NHibernate ISession object exposed through a Unit of Work pattern.  With the ISqlQuery object that gets created with the CreateSQLQuery() method, I can then specify that I want the results projected into my custom DTO:

var results = sqlQuery
    .SetResultTransformer(Transformers.AliasToBean(typeof(BulkLoadCustomer)))
    .List<BulkLoadCustomer>();

The AliasToBean method is a factory method on the static Transformers class.  I tell NHibernate to build a transformer to my DTO type, and finally use the List() method to execute the results.  I don’t have to specify any additional mapping file, and NHibernate never needs to know about that BulkLoadCustomer type until I build up the query.

The name “AliasToBean” is a relic of the Java Hibernate roots, which is why it didn’t jump out at me at first.  But it’s a great tool to use when you want to just map any table into a DTO, as long as the DTO matches up well to the underlying query results.

On a recent project, much of the application integration is done through bulk, batch processing.  Lots of FTP shuffling, moving files around, and processing large CSV or XML files.  Everything worked great with our normal NHibernate usage, until recently when we had to process historical transactional data.

The basic problem is that we had to calculate historical customer order totals.  Normally, this would be rather easy to do with a SQL-level bulk update.  However, in our case, we had to process the items one-by-one, as each transaction could potentially trigger an event, “reward earned”.  And naturally, the rules for this trigger are much too complex to attempt to do in straight T-SQL.

This meant that we still had to run our historical feed through the domain model.

A normal, daily drop of customer orders is processed fairly easily.  However, historical data over just the past year totaled close to 5 million transactions, each transaction being a single line in a CSV file.

Since a normal daily file would take about 2 hours to process, we simply could not wait the projected time to process all these transactions.  However, with some handy tips from the twitterverse, we were able to speed things up considerably.

Bulk import and export

The first thing we found is that if you have to do bulk, set-based processing, it was important to determine if this data is a bulk import, or bulk process.  Bulk import is extremely quick with tools like SQL Bulk Copy.  If you need to do a bulk import or export, use the right tool.  A bulk import of these rows into a single table takes about 2.5 minutes, versus days and days one transaction at a time.

In another process we needed to bulk load customer data.  The customer data matched fairly closely to our existing customer table, so we crafted a process that basically followed:

• Create table to match shape of CSV file
• Load CSV into table
• Issue single UPDATE statement to target table with the WHERE clause joining to the CSV-imported table

In this manner we were able to very, very quickly import millions of customer records very quickly.  However, if it’s not straight bulk import or export, we have to go through other channels.

Optimizing NHibernate for bulk processing

It was a lot of work tinkering with several different ideas, but ultimately the churn was worth it.  Here’s a few tips I picked up along the way:

Utilize the Unit of Work pattern and explicit transactions

When I first started, all processing was done with implicit transactions, and copious use of the Flush() method on ISession.  This meant that every. single. save. was in its own transaction.  When you look at the number of roundtrips this entailed, our database was just getting completely hammered.

Additionally, an ISession instance was disposed after every write to the database.  This meant that we could not take advantage of any of the first-level-cache support (aka, identity map) inherent in ISession.

Instead, I switched the codebase to use an actual Unit of Work, where I created a class that controlled the begin, commit and rollback of a unit of work:

public interface IUnitOfWork : IDisposable
{
    ISession CurrentSession { get; }
    void Begin();
    void Commit();
    void RollBack();
    bool IsActive { get; }
}

Before, we really had no control or understanding of the lifecycle of the ISession object.  With this pattern, its lifecycle is tied to the IUnitOfWork, allowing me to take advantage of other NHibernate features.

Use MultiCriteria/MultiQuery to batch SELECTs

MultiCriteria and MultiQuery allow you to send multiple SELECTs down the wire.  For each row in our table, we had to issue a SELECT, as processing a single transaction meant I needed to potentially affect the customer record as well as any previous order transaction records.  Doing this one SELECT at a time can be quite chatty, so I batched several together using MultiCriteria.

Just going from 1 at a time to 10 at a time, while insignificant for <100 records, can really add up once you get into the millions.

Use statement batching

In addition to SELECTs, we can also batch together INSERTs and UPDATEs.  In our case, we parameterized the processing of the file to a certain batch size (say, 250).  We then enabled NHibernate’s statement batching in the hibernate.cfg file:

<property name="adonet.batch_size">250</property>

And now instead of one INSERT being sent down the line at a time, we send a whole messload at once.  Profiling showed us that statement batching alone dropped the time by 50%.

NHibernate is very, very smart about knowing when and in what order to save things, so as long as items are persistent, we only really need to commit the transaction for the bulk processing to go through.

Process bulk updates in batches

Finally, once we had a proper Unit of Work implementation in place, we could now process the giant file as if it were many, smaller files.  We split the incoming work into batches of 250, then created a Unit of Work per batch.  This meant that an entire set of 250 was processed in a single transaction, instead of 5 million individual transactions.

Without a proper Unit of Work in place, we would not be able to do this.

Profiling is your friend

Finally, we needed a way to test our processing and the resulting speed improvements.  A simple automated test with stop watches in place let us tinker with the internals and observer the result.  With tools like NHProf, we could also observe what extra fetching we might need to do along the way.  Its suggestions also keyed us in to the various improvements we added along the way.

Wrapping it up

Bottom line is, if you can reduce the operation to a bulk import or export, the SQL tools will be orders of magnitude faster than processing one at a time.  But if you’re forced to go through your domain model and NHibernate, just be aware that your normal NHibernate usage will not scale.  Instead, you’ll need to lean on some of the built-in features that you don’t normally use to really squeeze as much performance as you can.

Back in the day, I used to develop scheduled tasks by writing my own task scheduler and batch execution program.  I don’t think at the time I knew about the Task Scheduler service built in to Windows.  It support just about any scheduling algorithm I could throw at it, outside of building dependent or cascading tasks.

For build automation, I often want to create, stop and start these scheduled tasks.  Luckily, there’s a handy command-line tool to do so: schtasks.exe.  Not only can you administer tasks on your own machine, but other machines as well.  This is perfect for build and deployment automation, where I need to not only copy files, but execute SQL migration scripts, start/stop services, and power down/up scheduled tasks.

The command-line tool lets you do quite a few things:

• Create a task
• Delete a task
• Run a task
• End a task
• Query a task for status/information
• Modify a task

I typically don’t create the tasks, as that really only needs to happen once.  However, it would be fairly trivial for me to do so, and have all of the task setup driven through automation.

One thing I like to do is disable batch jobs before the deployment happens, then turn them all back on.  I don’t want to do this with all the tasks there, so I use NAnt to pull from a text file of the scheduled tasks I’m interested in.  However, I don’t want to disable running tasks, as I want to just let them finish and have the build stop:

<echo message="Disabling batch jobs..." />
<foreach item="Line" in="batchjobs.txt" property="taskName">
    <exec program="schtasks.exe" 
                commandline="/Query /TN ${taskName} /FO TABLE /NH" 
                output="task.txt" />
    <loadfile file="task.txt" property="batchjob.info" />
    <exec program="schtasks.exe" 
                commandline="/CHANGE /TN ${taskName} /DISABLE" 
                if="${string::contains(batchjob.info, 'Ready')}"/>
</foreach>

In this NAnt snippet, I loop through the batch jobs I care about.  I then call the “schtasks.exe”, querying the tasks status by name and outputting the result in the form of a table to a “task.txt” file.  Next, I load that file into a NAnt property.  Finally, I use the “/CHANGE” switch to disable the scheduled task, but ONLY IF its status is “Ready” and not “Running” or something else.

Next, I’ll run through the batch jobs file again, this time querying for any task that hasn’t been disabled.  If there are any, I’ll just fail the build.  I could sleep the build script, and poll until the task completes.

Once the build is done, I’ll enable all the configured scheduled tasks:

<echo message="Enabling batch jobs..." />
<foreach item="Line" in="batchjobs.txt" property="taskName">
    <exec program="schtasks.exe" commandline="/CHANGE /TN ${taskName} /ENABLE" />
</foreach>

Build automation can really cut down on those launch-night headaches and uncertainty.  Having a good command-line tool goes a long way to enabling easy build automation scripts.

On a recent long project, our team’s commitment to continuous improvement led to some interesting results.  Originally, we started with quite a bit of the Scrum ceremony, such as sprint planning meetings, time-boxed iterations, and daily stand-ups.  However, since we practiced “whole team”, the daily stand-ups included around 25 people or so.  As a means of communicating information, these meetings tended to drag quite a bit.

As time went on, the importance of our daily stand-ups waned, to the point where in many cases we stopped doing them altogether.  It wasn’t that we didn’t find value in these meetings, but that instead we found better, more efficient ways to communicate information.

Waiting to communicate

In the daily stand-up, you answer three simple questions:

• What did I accomplish yesterday?
• What will I do today?
• What is preventing me from accomplishing today’s goals?

It took me a while to understand, but a conversation Scott Bellware a couple years back drove a simple point home.  Why are you waiting for a once-a-day meeting to bring up a blocking issue?  Unless this blocking issue happened in the previous 15 minutes before the meeting, how much did you waste by keeping the blocking issue internal?

Scott recommended that each of these questions could be more efficiently answered, and answered in a JIT fashion.  When you need to know the answer, just ask!  When you have a blocking issue, just raise it!  Don’t wait for the next day to raise the flag for help.

Examining the goals

The purposes of a daily stand-up include:

• Share commitment
• Communicate status, progress and plans
• Identify obstacles
• Set direction and focus
• Build a team

The problem I have with a daily stand-up is that no matter how short it is, it still stops everyone’s workflow for 10-20 minutes.  That’s 10-20 minutes of downtime, plus whatever time it takes to prepare, plus whatever time it takes to resume activities started before the meeting.

Often, the standup meeting takes place well after the time I’ve arrived at work.  It can take quite a bit of time to “prime the pump” and work efficiently.  Human beings do not deal well with interruptions and context switching.  While these goals are good, are there different, more efficient ways of dealing with them?

Sharing commitment

When I’ve worked with a strong, motivated team, shared commitment came naturally.  Everyone had a shared goal of moving stories to production in the shortest time possible.  Everything else that did not add value to that process was superfluous to that goal.

When our team did not have shared commitment, there were often larger issues at play.  It could be that the goals were not effectively communicated from management.  It could be that work habits were not in tune.  But often I’ve seen people shy away from the individual commitments that a stand-up brings.  You can say it’s a shared commitment, but that’s tough to do psychologically when the questions answered are centered around “I”.  What did “I” do yesterday.  What will “I” accomplish today, and so on.

Instead, I’ve seen that when a commitment made to the team isn’t met, when a mini-deadline is given, the person is often left in a negative, defensive position when the commitment isn’t met for whatever reason.

Communicate status, progress and plans

This can ALL be accomplished with a single, visible, shared and open story wall.  A story wall is a place where you can visually see where a story is in the overall process.  Ideally, the story wall is physical (or at least very visible to everyone).

All three of these items can be seen from a single story board.  Status is just where the story is in the pipeline.  Progress is how far it is along the journey, along with how long it’s been in the current bucket.  Planned work is simply the stories queued up.

Whenever status changes on a story, we move the story from phase to phase.  Whenever anyone wants to know where a story is, they can just look at the wall.  We initial our stories for who’s working on them, so if anyone wants to know more detailed status, they can go ask the individual person currently working on the story.

Identify obstacles

Again, why wait to bring up a blocking issue?  In our story board, we visually indicated a story was blocked by placing it either in a “blocked” bucket at the bottom, or placing a red Post-It note on it.  It was up to the person with the blocked story to communicate with the correct people, as soon as possible.

Set direction and focus

This could be another one of those cases where management should take care of this one.  The direction is to finish stories.  The focus is to finish the story you’re working on.  If you’re done with a story, pick up a new one.

If the process flow is clearly laid out, there really shouldn’t be a question of direction or focus.  For things like product direction, is this something that’s supposed to be communicated on a daily basis?

Build a team

I do admit, daily stand-ups do help build a team.  But for us, it was the shared conversation of how little value we were getting out of our stand-ups any more, besides just observing patterns in other’s daily reports.

I’m just not sure it’s worth stopping the entire line for 10-20 minutes every day to achieve this goal.  There are much more targeted ways for building a team other than a daily stand-up.  Like office Nerf wars, for example.

Achieving the goals

Daily stand-ups are a good way to meet the goals of a daily stand-up.  But that doesn’t mean it’s the only way.  As with any process, it’s important to constantly re-evaluate what the goals and values are, and how they relate back to the ultimate goal of the project.  If the goals are important, we should try to work to the most efficient means of achieving those goals.

For us, moving towards a lean-oriented approach, with a pull-based system, big visible story board, and keeping information visible to all achieved these goals in a more efficient manner.  That’s not to say that daily stand-ups are never a good idea, but I think it’s important to always evaluate the project activities to determine if there are other ways to meet the same goals.  Often, daily stand-ups are the most efficient means to achieve these goals.  In many other cases, it’s not.

As a quick review, a test fixture has inputs and outputs.  We set up our test fixture by configuring inputs.  We observe the results through the fixture’s outputs.

Inputs and outputs can be grouped into direct and indirect variants.  Direct inputs include:

• Constructor arguments
• Method arguments
• Property/field values

Indirect inputs are things we can’t directly set on our fixture.  An example would be a ShippingCalculatorService, that returns a shipping cost.  An order processor might use this service to calculate the full cost of an order.  However, we don’t directly set this shipping cost through the direct use of our order processor.  Instead, the shipping cost is an indirect input to our method through this shipping calculator.

On the other side of the coin are direct outputs, which include:

• Return values
• Mutated inputs
• Mutated fixture

Often, we just look at the return value of a method for the direct output.  But we might also look at one of the inputs, which might have mutated as the result of an operation.  We also have indirect outputs, which again are services whose methods are void.

If we properly follow Command-Query Separation, we can group our Rhino Mock usage into only two buckets:

• Stubbing indirect inputs
• Capturing indirect outputs

The first case is easy.  The second one can get ugly, as it requires the use of rather funky looking call.  Let’s say we have an order processor that reserves shipping spots through a service:

public interface IShippingReservationService
{
    void Reserve(int orderId, decimal totalWeight);
}

If we want to capture ALL arguments made and want to assert things, we must do something like:

IList<object[]> argsMade = shipper.GetArgumentsForCallsMadeOn(
    s => s.Reserve(0, 0m), 
    opt => opt.IgnoreArguments());

argsMade[0][0].ShouldEqual(batch1.Id);

Not too pretty.  I have to make sure I use the “IgnoreArguments” configuration option, so that I get all calls.  Next, I get an IList<object[]>, which is basically a jagged array of objects.  Everything is an object, so I have to cast if I want to do any special assertions.

But if we’re in C# 4.0, we can do better.

Capturing one argument-methods

I’d really like to capture all the arguments made as a single list of items. First, let’s look at the simple case where I have an indirect output with only ONE argument:

public interface IOrderProcessor
{
    void Process(OrderBatch batch);
}

In that case, I only want to capture the arguments made as a list of OrderBatch.  No real need to wrap that with anything else at this point.  To do this, I first set up my objects as I normally would with Rhino Mocks:

var processor = Stub<IOrderProcessor>();
var shipper = Stub<IShippingReservationService>();

var batchProcessor = new OrderBatchProcessor(processor, shipper);

The Stub method merely wraps MockRepository.GenerateStub().  From here, I want to then capture the arguments made.  In previous versions, I would do this by passing in a closure for the Do() method of Rhino Mocks.  I can extend this to a general case:

IList<OrderBatch> args = processor
    .Capture()
    .Args<OrderBatch>((p, batch) => p.Process(batch));

batchProcessor.ProcessBatches(new[]
{
    batch1, batch2, batch3
});

args.Count().ShouldEqual(3);
args.First().ShouldEqual(batch2);

I capture the arguments made as a list of OrderBatch, then call the ProcessBatches as normal.  I have some logic where express batches are processed first, which is why I assert that “batch2” came first.

The CaptureMethod is an extension method that begins a chain for me to start capturing arguments:

public static class MockExtensions
{
    public static CaptureExpression<T> Capture<T>(this T stub) 
        where T : class
    {
        return new CaptureExpression<T>(stub);
    }
}

I have to return a CaptureExpression<T> as a trick so that I don’t have to specify the stub’s type in my test.  My CaptureExpression<T> then lets me capture the args:

public class CaptureExpression<T>
    where T : class
{
    private readonly T _stub;

    public CaptureExpression(T stub)
    {
        _stub = stub;
    }

    public IList<U> Args<U>(Action<T, U> methodExpression)
    {
        var argsCaptured = new List<U>();

        Action<U> captureArg = argsCaptured.Add;
        Action<T> stubArg = stub => methodExpression(stub, default(U));

        _stub.Stub(stubArg).IgnoreArguments().Do(captureArg);

        return argsCaptured;
    }

In the Args method, I accept an expression detailing the method I want to call.  I create a list of the arguments, which is where I’ll stash them as they come in.  In the next couple of lines, I build the delegates that Rhino Mocks uses to both stub a method, and provide a stand-in callback.

Finally, I use the Stub() and Do() methods from Rhino Mocks to provide a replacement closure for calling the original method.  When the stubbed method is called, Rhino Mocks passes control to my CaptureArg method.  This method is a closure that adds the method argument to the “argsCaptured” list.

Initially, the list returned is empty.  But as the stub is used in the fixture, this list will be populated with the items used.

That’s the easy case of a single argument, let’s look at multiple arguments.

Capturing multiple arguments with tuples

I’d also like group the arguments made from each call into a single object, instead of just an array that I have to then poke around in.  In earlier versions of C#, I would need to craft an object to hold these values.  In C# 4.0, I have the Tuple classes.

I’ll follow the same pattern here as the method above, except this time use the Tuple class to group the method arguments together:

public IList<Tuple<U1, U2>> Args<U1, U2>(Action<T, U1, U2> methodExpression)
{
    var argsCaptured = new List<Tuple<U1, U2>>();

    Action<U1, U2> captureArg = (u1, u2) => argsCaptured.Add(Tuple.Create(u1, u2));
    Action<T> stubArg = stub => methodExpression(stub, default(U1), default(U2));

    _stub.Stub(stubArg).IgnoreArguments().Do(captureArg);

    return argsCaptured;
}

I return a Tuple<U1, U2>, which are the types of the method parameters of the stubbed method, but now just grouped together in a strongly-typed bucket.  I can now create strongly-typed assertions about my indirect outputs:

var processor = Stub<IOrderProcessor>();
var shipper = Stub<IShippingReservationService>();

var args = shipper
    .Capture()
    .Args<int, decimal>((s, orderId, weight) => s.Reserve(orderId, weight));

var batchProcessor = new OrderBatchProcessor(processor, shipper);

batchProcessor.ProcessBatches(new[]
{
    batch1, batch2
});

args.Count.ShouldEqual(2);
args[0].Item1.ShouldEqual(batch1.Id);
args[0].Item2.ShouldEqual(batch1.TotalWeight);
args[1].Item1.ShouldEqual(batch2.Id);
args[1].Item2.ShouldEqual(batch2.TotalWeight);

Additionally, because I don’t have to guess at the number of arguments made, the Tuple returned is linked to the number of arguments to the stubbed method.  This provides a much stronger link between the arguments I capture and the method being stubbed.

From here, it’s trivial to extend this approach to as many arguments as I need.  And as long as I stick to CQS, and my methods either do something or answer a question, these are the only mocking requirements I’ll need.  As always, you can find this example on my github.

It took me a while to really settle in to a Git workflow I like to use on a daily basis.  It’s a pretty common workflow, and is centered around local topic branches and rebasing.  It’s not actually much different than the workflow I used with SVN, except that I prefer rebase over merge.  My typical Git workflow starts out with:

• git checkout –b “SomeTopic”
• <work work>
• git add .
• git commit –am “Commit message”
• <repeat last 2 steps as necessary>
• git checkout master
• git pull --rebase origin master
• git checkout SomeTopic
• git rebase master
• git checkout master
• git rebase SomeTopic (or merge, same thing)
• git push origin master
• git branch –d SomeTopic

In a nutshell, all work, and I mean ALL WORK, is done in a local branch.  Every time.  This is because I can never predict when other, unrelated work might come up.  I do work in a local branch.  When I want to bring that work back to master (basically, trunk), I first do a pull from origin back to master, rebasing my existing commits.

At this point, I should note that I rarely, rarely ever need to rebase upstream changes.  If I pull work back to master, that means that I’m about to push.  Otherwise, it can just stay in a local topic branch.

Anyway, I make sure that my master reflects the absolute latest upstream changes.  When I’m ready to bring the local branch back in, INSTEAD OF MERGING, I rebase the branch on to master.  All this means in practice is that the branch’s commits are re-played onto the master branch.  Merging instead squashes all the branch’s work in to one single merge commit, which I’d rather avoid.

Side note – The git “rebase considered harmful” article is 3 years old.  A lot of opinions have changed since then, so while its core arguments do apply (never rebase a pushed commit), rebase is a sharp, useful tool that does great things when used right.

Finally, I do a merge/rebase from master to the branch, which really just does a fast-forward merge.  Because the SomeTopic pointer is a descendant of the master pointer, a merge/rebase is really just moving the master pointer up to the SomeTopic pointer.  Once this is done, I push and I’m finished.

Translating this to Hg has been a little more difficult, however.

Combining Rebase and Bookmarks

Right now, I’m trying to use Bookmarks and Rebase to achieve this same workflow.  The basic workflow I want is:

• All work is always isolated from any other work
• Pulling latest does not affect isolated work
• Isolated work, when rolled back in, has linear history preserved

I don’t really care how this is accomplished.  So, I’m going from this article on the different ways of doing branching in Mercurial.

So my first try was using the Hg extensions Rebase and Bookmarks, which have both been included with Mercurial for a while now.  On the surface, Rebase and Bookmarks seem very similar to Git’s rebase and branching model.

Mimicking git, I try:

• hg bookmark SomeTopic
• <work work>
• hg commit –Am “Some message”

Now I want to pull those changes back to master…but wait, there is no master!  I don’t have a pointer to when I first made the branch, and even worse, the “default” branch is now sitting on my SomeTopic branch.

What I’d really like to do is do “hg checkout default”, then do an update, so that “default” always represents the upstream current state.  But “default” has moved!

My next attempt was to create a “master” bookmark right before I created the “SomeTopic” bookmark, so that “master” mimics the Git master branch – that is, it’s merely a named pointer, nothing special.

I now want to do some more, unrelated work, so I:

• hg update master
• hg bookmark SomeOtherTopic
• <work work>
• hg commit –Am “Some other message”

At this point, here’s my tree:

As we can see here, I have my master bookmark marking where I diverged my bookmarks.  This now more or less matches what I see in Git, with the exception of that “default” branch.

Let’s say that we now want to bring “SomeTopic” back to “master”.  Really, I want to rebase “SomeTopic” on to “master”.  Because “master” is a parent of SomeTopic, this should really just be a fast-forward merge.  The master should just be moved up to SomeTopic.

If there were upstream changes, that would change the story a bit.  Master would move up to those upstream changes, and all changes from where SomeTopic and master diverged would be replayed on top of master.  One thing to note is that Git is very smart about fast-forward merges.  If I rebase SomeTopic on to master, and master is still where it was, nothing would happen.  I could then rebase master on to SomeTopic (or merge), and master would just move up.

In the picture above, I really just want “master” to move up to “SomeTopic”, then I can push “master” up.  So let’s try to do an hg rebase:

• hg rebase –b SomeTopic –d master

I want to rebase SomeTopic on top of master.  I get a message “nothing to rebase”.  That’s fine, as I have nothing to do here anyway.  “master” is in the direct ancestry of “SomeTopic”.

The next thing I want to do is move master to SomeTopic, which at this point should just be a fast-forward merge.  But nothing I seem to do will allow me to move “master” up to “SomeTopic”.  I try all of these:

• hg update master/hg merge –r SomeTopic <- “nothing to merge”
• hg rebase –b master –d SomeTopic <- “nothing to rebase”

Blarg.  Even though I’ve configured my bookmark to automatically move forward, there doesn’t seem to be a way to do this myself.  What I can do is:

• hg bookmark –d master
• hg update SomeTopic
• hg bookmark master
• hg bookmark –d SomeTopic

This basically fast-foward merges the master bookmark to SomeTopic, by…deleting it and re-creating it.  If Mercurial supported a fast-forward merge here, that would be GREAT, but it doesn’t, so I have to jump through a bunch of hoops here.  All of which I could batch up in to a “fast-forward” alias, but is still annoying, as Git just handles this automatically.

Anyway, this is now the state of things:

And now I want to push “master” up.  But this will be interesting, I don’t want “SomeOtherTopic” to go out.  So, I use:

• hg push –b master

Now only the “master” piece got pushed up.  Let’s say we now want to get the SomeOtherTopic back in to the fold, AND, that there were upstream changes.  In this case, we want to update our master to be include new changes, but without affecting “SomeOtherTopic”.  We do this to update our master:

• hg update master
• hg pull --rebase –b default

This makes our local repository tree now:

Exactly what we wanted! The “master” bookmark got moved up, past “SomeOtherTopic”.  Now, we just need to rebase SomeOtherTopic onto master:

• hg rebase –b SomeOtherTopic –d master

This means I’m replaying the SomeOtherTopic on top of master, resulting in the following tree:

Looking good!  I now just follow the FF-merge-master-to-branch routine:

• hg update SomeOtherTopic
• hg bookmark –f master <- basically moves master to current location, better than delete/add
• hg bookmark –d SomeOtherTopic <- delete the bookmark (the work is integrated now)
• hg push –b master

Well, that’s it.  It’s not completely like git branching, there are some caveats here and there, as git handles remotes different than Hg.  Git also automatically handles fast-forward merges, but in practice, I don’t think that it’ll be a big deal.

I need to run with this with a team to really make sure it doesn’t corrupt things, but it seems to work so far.

Other posts in this series:

• Controllers
• Contextual controller injection
• Filters
• Action Results
• Views

In this series, we’ve looked on how we can go beyond the normal entry point for dependency injection in ASP.NET MVC (controllers), to achieve some very powerful results by extending DI to filters, action results and views.  We also looked at using the modern IoC container feature of nested containers to provide injection of contextual items related to both the controller and the view.

In my experience, these types of techniques prove to be invaluable over and over again.  However, not every framework I use is built for dependency injection through and through.  That doesn’t stop me from getting it to work, in as many places as possible.

Why?

It’s really amazing how much your design changes once you remove the responsibility of locating dependencies from components.  But instead of just talking about it, let’s take a closer look at the alternatives, from the ASP.NET MVC 2 source code itself.

ViewResult: Static Gateways

One of my big beefs with the design of the ActionResult concept is that there are two very distinct responsibilities going on here:

• Allow an action method to describe WHAT to do
• The behavior of HOW to do it

Controller actions are testable because of the ActionResult concept.  I can return a ViewResult from a controller action method, and simply test its property values.  Is the right view name chosen, etc.

The difficulty comes in to play when it becomes harder to understand what is needed for the HOW versus the pieces describing the WHAT.  From looking at this picture, can you tell me which is which?

Offhand, I have no idea.  The ViewName member I’m familiar with, but what about MasterName in the ViewResult class?  Then you have a “FindView” method, which seems like a rather important method.  The other pieces are all mutable, that is, read and write.  Poring over the source code, none of these describe the WHAT, that’s just the ViewName and MasterName.  Those are the pieces the ViewEngineCollection uses to find a view.

Then you have the View property which can EITHER be set in a controller action, or is dynamically found by looking at the ViewEngineCollection.  So let’s look at that property on the ViewResultBase class:

[SuppressMessage("Microsoft.Usage", "CA2227:CollectionPropertiesShouldBeReadOnly",
    Justification = "This entire type is meant to be mutable.")]
public ViewEngineCollection ViewEngineCollection {
    get {
        return _viewEngineCollection ?? ViewEngines.Engines;
    }
    set {
        _viewEngineCollection = value;
    }
}

Notice the static gateway piece.  I’m either returning the internal field, OR, if that’s null, a static gateway to a “well-known” location.  Well-known, that is, if you look at the source code of MVC, because otherwise, you won’t really know where this value can come from.

So why this dual behavior?

Let’s see where the setter is used:

The setter is used only in tests.  All this extra code to expose a property, this null coalescing behavior for the static gateway (referenced in 7 other places), all just for testability.  Testing is supposed to IMPROVE design, not make it more complicated and confusing!

I see this quite a lot in the MVC codebase.  Dual responsibilities, exposition of external services through lazy-loaded properties and static gateways.  It’s a lot of code to support this role of exposing things JUST for testability’s sake, but is not actually used under the normal execution flow.

So what you wind up happening is a single class that can’t really make up its mind on what story it’s telling me.  I see a bunch of things that seem to help it find a view (ViewName, MasterName), as well as the ability to just supply a view directly (the View property).  I also see exposing through properties things I shouldn’t set in a controller action.  I can swap out the entire ViewEngineCollection for something else, but really, is that what I would ever want to do?  You have pieces exposed at several different conceptual levels, without a very clear idea on how the end result will turn out.

How can we make this different?

Separating the concerns

First, let’s separate the concepts of “I want to display a view, and HERE IT IS” versus “I want to display a view, and here’s its name”.  There are also some redundant pieces that tend to muddy the waters.  If we look at the actual work being done to render a view, the amount of information actually needed becomes quite small:

public class NamedViewResult : IActionMethodResult
{
    public string ViewName { get; private set; }
    public string MasterName { get; private set; }

    public NamedViewResult(string viewName, string masterName)
    {
        ViewName = viewName;
        MasterName = masterName;
    }
}

public class ExplicitViewResult : IActionMethodResult
{
    public IView View { get; private set; }

    public ExplicitViewResult(IView view)
    {
        View = view;
    }
}

Already we see much smaller, much more targeted classes.  And if I returned one of these from a controller action, there’s absolutely zero ambiguity on what these class’s responsibilities are.  They merely describe what to do, but it’s something else that does the work.  Looking at the invoker that handles this request, we wind up with a signature that now looks something like:

    public class NamedViewResultInvoker : IActionResultInvoker<NamedViewResult>
    {
        private readonly RouteData _routeData;
        private readonly ViewEngineCollection _viewEngines;

        public NamedViewResultInvoker(RouteData routeData, ViewEngineCollection viewEngines)
        {
            _routeData = routeData;
            _viewEngines = viewEngines;
        }

        public void Invoke(NamedViewResult actionMethodResult)
        {
            // Use action method result
            // and the view engines to render a view

Note that we only use the pieces we need to use.  We don’t pass around context objects, whether they’re needed or not.  Instead, we depend only on the pieces actually used.  I’ll leave the implementation alone as-is, since any more improvements would require creation of more fine-grained interfaces.

What’s interesting here is that I can control how the ViewEngineCollection is built, however I need it built.  Because I can now use my container to build up the view engine collection, I can do things like build the list dynamically per request, instead of the singleton manner it is now.  I could of course build a singleton instance, but it’s now my choice.

The other nice side effect here is that my invokers start to have much finer-grained interfaces.  You know exactly what this class’s responsibilities are simply by looking at its interface.  You can see what it does and what it uses.  With broad interfaces like ControllerContext, it’s not entirely clear what is used, and why.

For example, the underlying ViewResultBase only uses a small fraction of ControllerContext object, but how would you know?  Only by investigating the underlying code.

New Design Guidelines

I think a lot of the design issues I run into in my MVC spelunking excursions could be solved by:

1. Close attention to SOLID design
2. Following the Tell, Don’t Ask principle
3. Favoring composition over inheritance
4. Favoring fine-grained interfaces

So why doesn’t everyone just do this?  Because design is hard.  I still have a long ways to go, as my current AutoMapper configuration API rework has shown me.  However, I do feel that careful practice of driving design through behavioral specifications realized in code (AKA, BDD) goes the farthest to achieving good, flexible, clear design.

While driving design with unit tests, I often break behaviors out into separate classes, both to increase cohesion, and as a side effect, increase testability.  Occasionally, I run into situations where I have some sort of environmental variable that never changes.  Or, if it does change, it would take an act of Congress.

When designing these environmental “astronomical constants”, I take the “JFHCI” approach.  These are values that have never changed, and the customer has told us don’t need to change.  One case I ran in to recently is a reward limit.  If you purchase over X dollars, you earn a reward.  The value X does not change, so I made it a constant:

public const decimal GadgetSpendRewardLimit = 200m;

My “testability” hat on says that constants are bad, and that I need to be able to properly set up all environmental variables.  However, in this case, allowing this value to change in ANY way produces a design that does not match reality.  In reality, this reward limit does not need to change.

Instead of going through a bunch of hoops to allow this value to change solely for testing, I’ll leave the value alone.  However, in the off chance that this value DOES change, my tests make the assumption that this value is this constant.

So, I’ve introduced testing assumptions made in my tests with a set of preconditions in the setup portion of the test:

[SetUp]
public void SetUp()
{
    Debug.Assert(Customer.GadgetSpendRewardLimit == 200m, "Assumes threshold is $200");

I use a Debug.Assert mostly just to signify that I don’t need to test this every time, so I don’t really need a regular test assertion.  Instead, this is just a fail-safe, and matches the intent of assumption validation, rather than behavior validation.

With assumption checking through preconditions, I keep the correct design (an immutable constant), while providing explicit callouts of assumptions made about the “correctness” of my tests.  If my assumptions are wrong, I won’t bother trying to continue the test, as the base set of assumptions the test was built around are no longer valid.

A quick way to explain a set of differing opinions is to label it as “a religious argument”.  In a post about using MEF on NerdDinner, Scott Hanselman showed an example on using poor man’s DI versus regular DI.  Now, the post wasn’t about that topic, but more on how to integrate MEF with ASP.NET MVC.  I do get rather annoyed at comments like this however (emphasis mine):

The second constructor takes an IDinnerRepository, allowing us to make different implementations, but the default constructor says, "well, here's a concrete implementation if you don't give one." It's a slippery slope and by adding the default implementation I get to sidestep using dependency injection while making the controller testable, but I've tied my controller down with a direct dependency to the DinnersController. This is sometimes called "Poor Man's IoC" and many would say that this is a very poor man. That's a religious argument, but Hammett takes a stand by removing the default constructor.

I see a religious argument is an argument whose opposite positions aren’t based in facts, but opinions.  It’s reasoning based on assumptions that are grounded in either faith, ignorance or a matter of opinion.

Something like poor man’s DI versus actual DI is different.  Let’s compare the code.  First, poor man’s DI:

public class DinnersController
{
    private readonly IDinnerRepository dinnerRepository;

    public DinnersController() : this(new DinnerRepository())
    {
    }

    public DinnersController(IDinnerRepository repository)
    {
        dinnerRepository = repository;
    }

Now, regular DI:

public class DinnersController
{
    private readonly IDinnerRepository dinnerRepository;

    public DinnersController(IDinnerRepository repository)
    {
        dinnerRepository = repository;
    }

In comparison, the poor man’s DI example:

• Has more code
• Is coupled to a specific implementation
• Decides its component’s lifecycle

This isn’t just in the controller, every component used must use this technique.  Anything that DinnerRepository uses also would have to employ this technique, as we’re using the no-argument constructor for DinnerRepository.

I don’t know about you, but if I can write less code and gain the benefits of looser coupling and externalizing component lifecycle, that’s a win.

Let’s review.

Poor man’s DI: more code, more coupled, no flexibility

Regular DI: less code, less coupled, high flexibility

It was a failure in teaching dependency injection that the argument was made based on testability.  It only helps those already doing TDD to shape design, rather than just writing tests.

Instead, DI is about creating highly flexible components, both in lifecycle and component selection.  DI removes component resolution responsibilities from classes, therefore removing code.  And less code is ALWAYS a good thing.

Other posts in this series:

• Controllers
• Contextual controller injection
• Filters
• Action Results

And now for a bit more controversial shift.  While most folks doing DI in ASP.NET MVC see the benefit of the ability to provide injection around the controller-side of things (filters, action results, controllers etc.), I’ve also seen a lot of benefit from injection on the view side.  But before delve into the how, let’s first look at the why.

The responsibility of a view is to render a model.  Pretty cut and dry, until you start to try and do more interesting things in the view.  Up until now, the CODE extensibility points of a view included:

• XyzHelper extensions (UrlHelper, AjaxHelper, HtmlHelper)
• Custom base view class with custom services

I’m leaving out markup extensibility points such as MVC 2 templated helpers, master pages, partials, render action and so on.  If we want our custom helper extension method to use a service, such as a custom Url resolver, localization services, complex HTML builders and so on, we’re left with service location, looking something like this:

public static MvcHtmlString Text<TModel>(this HtmlHelper<TModel> helper, string key)
{
    var provider = ObjectFactory.GetInstance<ILocalizationProvider>();

    var text = provider.GetValue(key);

    return MvcHtmlString.Create(text);
}

We started seeing this sort of cruft all over the place.  It became clear quite quickly that HtmlHelper extensions are only appropriate for small, procedural bits of code.  But as we started building customized input builders (this was before MVC 2’s templated helpers and MVC Contrib’s input builders), the view started becoming much, much more intelligent about building HTML.  Its responsibilities were still just “build HTML from the model”, but we took advantage of modern OO programming and conventions to drastically reduce the amount of duplication in our views.

But all of this was only possible if we could inject services into the view.  Since MVC isn’t really designed with DI everywhere in mind, we have to use quite a bit of elbow grease to squeeze out the powerful designs we wanted.

Building an injecting view engine

Our overall strategy for injecting services into the view was:

• Create a new base view class layer supertype
• Expose services as read/write properties
• Utilize property injection to build up the view

Since we’re using the WebFormsViewEngine, we don’t really have any control over view instantiation.  We have to use property injection instead.  That’s not a big hurdle for us here as it was in other place.  We’re not instantiating views in unit tests, which are a big source of confusion when doing property injection.

First, we need to subclass the existing view engine and plug in to its existing behavior:

public class NestedContainerViewEngine : WebFormViewEngine
{
    public override ViewEngineResult FindView(
        ControllerContext controllerContext, 
        string viewName, string masterName, bool useCache)
    {
        var result = base.FindView(controllerContext, viewName, masterName, useCache);

        return CreateNestedView(result, controllerContext);
    }

    public override ViewEngineResult FindPartialView(
        ControllerContext controllerContext, 
        string partialViewName, bool useCache)
    {
        var result = base.FindPartialView(controllerContext, partialViewName, useCache);

        return CreateNestedView(result, controllerContext);
    }

We’re going to use the base view engine to do all of the heavy lifting for locating views.  When it finds a view, we’ll create our ViewEngineResult based on that.  The CreateNestedView method becomes:

private ViewEngineResult CreateNestedView(
    ViewEngineResult result, 
    ControllerContext controllerContext)
{
    if (result.View == null)
        return result;

    var parentContainer = controllerContext.HttpContext.GetContainer();

    var nestedContainer = parentContainer.GetNestedContainer();

    var webFormView = (WebFormView)result.View;

    var wrappedView = new WrappedView(webFormView, nestedContainer);

    var newResult = new ViewEngineResult(wrappedView, this);

    return newResult;
}

We want to create a nested container based on the calling controller’s nested container.  Our previous controller factory used a static gateway to store the outermost nested container in HttpContext.Items.  To make it visible to our view engine (which is SINGLETON), we have no choice but to build a little extension method in GetNestedContainer for HttpContextBase to retrieve our nested container.

Once we have the outermost nested container, we create a new, child nested container from it.  Containers can nest as many times as we like, inheriting the parent container configuration.

From there, we then need to build up our own IView instance, a WrappedView object.  Unfortunately, the extension points in the WebFormView class do not exist for us to seamlessly extend it to provide injection.  However, since MVC is open source, we have a great starting point.

After we build our WrappedView, we create our ViewEngineResult and our custom view engine is complete.  Before we look at the WrappedView class, let’s look at how our views will be built.

Layer supertype to provide injection

To provide injection of services, we’ll need a layer supertype between our actual views and the normal MVC ViewPage and ViewPage<T>:

public abstract class ViewPageBase<TModel> : ViewPage<TModel>
{
    public IHtmlBuilder<TModel> HtmlBuilder { get; set; }
}

public abstract class ViewPageBase : ViewPageBase<object>
{
}

Here, we include our custom IHtmlBuilder service that will do all sorts of complex HTML building.  We can include any other service we please, but we just need to make sure that it’s a mutable property on our base view layer supertype.  The HtmlBuilder implementation does nothing interesting, but includes a set of services we want to have injected:

public class HtmlBuilder<TModel> : IHtmlBuilder<TModel>
{
    private readonly HtmlHelper<TModel> _htmlHelper;
    private readonly AjaxHelper<TModel> _ajaxHelper;
    private readonly UrlHelper _urlHelper;

    public HtmlBuilder(
        HtmlHelper<TModel> htmlHelper, 
        AjaxHelper<TModel> ajaxHelper, 
        UrlHelper urlHelper)
    {
        _htmlHelper = htmlHelper;
        _ajaxHelper = ajaxHelper;
        _urlHelper = urlHelper;
    }

When we configure our container, we want any service used to be available.  By configuring the various helpers, we allow our helpers to be injected instead of passed around everywhere in method arguments.  This is MUCH MUCH cleaner than passing context objects around everywhere we go, regardless if they’re actually used or not.

Wrapping WebFormView to provide injection

As I mentioned before, we can’t subclass WebFormView directly, but we can instead wrap its behavior with our own.  Composition over inheritance, but we still have to duplicate more behavior than I would have liked.  But, it’s about the cleanest and lowest-impact implementation I’ve come up with, and gets around any kind of sub-optimal poor-man’s dependency injection.

First, our WrappedView definition:

public class WrappedView : IView, IDisposable
{
    private bool _disposed;

    public WrappedView(WebFormView baseView, IContainer container)
    {
        BaseView = baseView;
        Container = container;
    }

    public WebFormView BaseView { get; private set; }
    public IContainer Container { get; private set; }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed)
            return;

        if (Container != null)
            Container.Dispose();

        _disposed = true;
    }

We accept the base view (a WebFormView created from the original WebFormsViewEngine), as well as our nested container.  We need to dispose of our container properly, so we implement IDisposable properly.

Now, the next part is large, but only because I had to duplicate the existing MVC code to add in what I needed:

public void Render(ViewContext viewContext, TextWriter writer)
{
    if (viewContext == null)
    {
        throw new ArgumentNullException("viewContext");
    }

    object viewInstance = BuildManager.CreateInstanceFromVirtualPath(BaseView.ViewPath, typeof(object));
    if (viewInstance == null)
    {
        throw new InvalidOperationException(
            String.Format(
                CultureInfo.CurrentUICulture,
                "The view found at '{0}' was not created.",
                BaseView.ViewPath));
    }

    ////////////////////////////////
    // This is where our code starts
    ////////////////////////////////
    var viewType = viewInstance.GetType();
    var isBaseViewPage = viewType.Closes(typeof (ViewPageBase<>));

    Container.Configure(cfg =>
    {
        cfg.For<ViewContext>().Use(viewContext);
        cfg.For<IViewDataContainer>().Use((IViewDataContainer) viewInstance);

        if (isBaseViewPage)
        {
            var modelType = GetModelType(viewType);
            var builderType = typeof (IHtmlBuilder<>).MakeGenericType(modelType);
            var concreteBuilderType = typeof (HtmlBuilder<>).MakeGenericType(modelType);

            cfg.For(builderType).Use(concreteBuilderType);
        }
    });

    Container.BuildUp(viewInstance);
    ////////////////////////////////
    // This is where our code ends
    ////////////////////////////////

    var viewPage = viewInstance as ViewPage;
    if (viewPage != null)
    {
        RenderViewPage(viewContext, viewPage);
        return;
    }

    ViewUserControl viewUserControl = viewInstance as ViewUserControl;
    if (viewUserControl != null)
    {
        RenderViewUserControl(viewContext, viewUserControl);
        return;
    }

    throw new InvalidOperationException(
        String.Format(
            CultureInfo.CurrentUICulture,
            "The view at '{0}' must derive from ViewPage, ViewPage<TViewData>, ViewUserControl, or ViewUserControl<TViewData>.",
            BaseView.ViewPath));
}

I’m going to ignore the other pieces except what’s between those comment blocks.  We have our ViewPageBase<TModel>, and we need to configure various services for our views, including:

• ViewContext
• Anything needed by the helpers (IViewDataContianer)
• Custom services, like IHtmlBuilder<TModel>

Just like our previous nested container usage, we take advantage of StructureMap’s ability to configure a container AFTER it’s been created.  We first configure ViewContext and IViewDataContainer (needed for HtmlHelper).  Finally, we determine the TModel model type of our view, and configure IHtmlBuilder<TModel> against HtmlBuilder<TModel>.  If TModel is of type Foo, we configure IHtmlBuilder<Foo> to use HtmlBuilder<Foo>.

Finally, we use the BuildUp method to perform property injection.  Just as we explicitly configured property injection for our filter’s services, we need to do the same for the view’s services:

SetAllProperties(c =>
{
    c.OfType<IActionInvoker>();
    c.OfType<ITempDataProvider>();
    c.WithAnyTypeFromNamespaceContainingType<ViewPageBase>();
    c.WithAnyTypeFromNamespaceContainingType<LogErrorAttribute>();
});

The view services are all contained in the namespace of the ViewPageBase class.  With that in place, we just have one more piece to deal with: services in master pages.

Dealing with master pages

In the RenderViewPage method, we add a piece to deal with master pages and enable injection for them as well:

private void RenderViewPage(ViewContext context, ViewPage page)
{
    if (!String.IsNullOrEmpty(BaseView.MasterPath))
    {
        page.MasterLocation = BaseView.MasterPath;
    }

    page.ViewData = context.ViewData;

    page.PreLoad += (sender, e) => BuildUpMasterPage(page.Master);

    page.RenderView(context);
}

Because master pages do not flow through the normal view engine, we have to hook in to their PreLoad event to do our property injection in a BuildUpMasterPage method:

private void BuildUpMasterPage(MasterPage master)
{
    if (master == null)
        return;

    var masterContainer = Container.GetNestedContainer();

    masterContainer.BuildUp(master);

    BuildUpMasterPage(master.Master);
}

If we needed any custom configuration for master pages, this is where we could do it.  In my example, I don’t, so I just create a new default nested container from the parent container.  Also, master pages can have nesting, so we recursively build up all of the master pages in the hierarchy until we run out of parent master pages.

Finally, we need to hook up our custom view engine in the global.asax:

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();

    RegisterRoutes(RouteTable.Routes);

    StructureMapConfiguration.Initialize();

    var controllerFactory = new StructureMapControllerFactory(ObjectFactory.Container);

    ControllerBuilder.Current.SetControllerFactory(controllerFactory);

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

And that’s it!  With our nested container view engine in place, we can now inject complex UI services in to our views, allowing us to create powerful UI content builders without resorting to gateways or service location.

Conclusion

It was a bit of work, but we were able to inject services into not only views, but partials, master pages, even MVC 2 templated helpers!  By using nested containers, we were able to configure all of the contextual pieces so that services built for each view got the correct contextual item (the right HtmlHelper, ViewContext, IViewDataContainer, etc.)

This is a quite powerful tool now, we don’t need to resort to ugly usage of static gateways or service location.  We can now build UI services that depend on an HtmlHelper or ViewContext, and feel confident that our services get the correct instance.  In the past, we’d need to pass around our ViewContext EVERYWHERE in order to get back at these values.  Not very fun, especially when you start to see interfaces that accept everything under the sun “just in case”.

For those folks that don’t want to inject services in to their views, it’s all about responsibilities.  I can create encapsulated, cohesive UI services that still only create HTML from a model, but I’m now able to use actual OO programming without less-powerful static gateways or service location to do so.

So looking back, we were able to inject services into our controllers, filters, action results and views.  Using nested containers, we were able to provide contextual injection of all those context objects that MVC loves to use everywhere.  But now we can let our services use them only when needed through dependency injection, providing a much cleaner API throughout.

You can find code for this example on my github:

http://github.com/jbogard/blogexamples

C# 4.0 includes lots of shiny new hammers for us to bang away at every new and existing development problem we face.  One of the more interesting features is the concept of named and optional parameters.  Consider this rather cryptic bit of code:

var match = Regex.IsMatch("abcde", "cd");

So which argument is the pattern, and which is the input to match against?  With named parameters, this becomes much easier to understand:

var match = Regex.IsMatch(input: "abcde", pattern: "cd");

It’s now immediately clear which method parameter is which. That’s fantastic, this feature alone saves me tons of headaches when I order parameters incorrectly to a function that accepts objects of the same type. 

Also part of C# 4.0 are optional parameters, which can save quite a bit of typing by reducing the number of overloads to a function.  However, optional parameters come with a few caveats worth noting.

Expressions not supported

Let’s look at this typical controller action:

public ViewResult Index(int? minSessions)
{
    minSessions = minSessions ?? 0;

    var list = from conf in _repository.Query()
               where conf.SessionCount >= minSessions
               select conf;

I have a list view of conferences, that optionally filters on the minimum number of sessions.  In my screen, the user has a drop-down to select this minimum session count filter.  Since I don’t require this in the UI, I make that parameter a nullable int.

However, I still have to deal with the user not applying the filter, so I have some code to deal with this.  I could instead try to take advantage of optional parameters:

public ViewResult Index(int minSessions = 0)
{
    var list = from conf in _repository.Query()
               where conf.SessionCount >= minSessions
               select conf;

With the optional parameter syntax, I set the default value of minSessions to 0, removing that annoying cruft in the body of the controller action.  The action becomes much more readable.  However, I immediately run into problems when I try and compile the rest of my code base, and find that this no longer compiles:

return this.RedirectToAction(c => c.Index());

I don’t get any errors from ReSharper, but when I compile, I get a compile error:

error CS0854: An expression tree may not contain a call or invocation that uses optional arguments

Well that stinks!  I use expressions all the time to reference controller actions, as it gives me a strongly-typed links and URLs, instead of loose-typed, string-based versions.  It seems like the compiler should be able to build the correct expression tree, because the normal compiler can!  It could generate a regular Expression.Constant as if I passed in the default argument value.

But it doesn’t, and I get this compiler error instead.  So just be aware, if you want your code to be consumed by expressions, you cannot use optional arguments.

Default value localization

Another caveat C# folks might not know about is that the C# version of optional parameters suffers from the same limitations of the VB version (which, by the way, has been in VB since VS 2002).  Namely, the optional parameter value is a compiler trick, where the optional parameter value is not compiled into the method called, but instead into the caller.  Here’s an example, from a unit test:

var controller = new ConferenceController(repository, mapper);

var result = controller.Index();

result.ViewData.Model.ShouldEqual(viewModel);

I call the Index action method, which includes an optional argument.  If we open the compiled code from here, we see that the optional parameter value is baked in to the call site:

So what does this mean for us?  If we change the value of the optional argument from 0 to 1, we have to recompile all calling code for the calling code to get the updated value!

For folks shipping assemblies for a living, this means that optional argument values don’t version well, as callers have to recompile.  When I used to work for a company whose product included a DLL, we avoided optional method arguments for just this reason.  It’s not a reason not to use optional arguments, but it’s important to understand how they work so that you don’t run into headaches later.

A lot of what I try to do on this blog, user group presentations, and other community events is to try and share the knowledge and experience that I and my teammates have built up over the years.  I’ve hosted talks on “How we do MVC” and things of that nature, blogged about our setup and so on.

However, it’s still tough to take away from these interactions something that a developer could take back to their team and immediately start writing maintainable ASP.NET MVC applications.  Instead, a more immersive, hands-on instruction is needed.  That’s why we created the ASP.NET MVC Boot Camp.

Out-of-the-box, ASP.NET MVC provides little to no guidance on how to successfully deliver MVC applications, which features to embrace, which to avoid and so on.  In our 3-day course, I go through ASP.NET MVC from soup to nuts, walking through how we’ve used ASP.NET MVC to build clean, maintainable applications.  At the end of the course, you’ll be able to go back to your team with the knowledge of how to build ASP.NET MVC 2 applications successfully.

The class runs 3 days from May 26th to May 28th (in 2 weeks), and there’s an available discount if you call Headspring at 512-459-2260.

So if you’re interested in how we do MVC and want to hit the ground running and skip all the trial and error that we had to go through, call us to enroll.  As part of the class, you also get 3 days to ask as many questions you like on how we use dependency injection, automated builds, source control, NHibernate, and anything else you’re curious about.  Hope to see you there!

It took quite a while (around 2 months) for me to finally become comfortable with Git.  Why so long?  One of the benefits of Git is that it’s very powerful.  It’s also one of the drawbacks.  It was a bit of a journey to unlearn all the knowledge and habits I’ve picked up with SVN and TFS over the years.  Along the way, I picked up a few pointers around using Git that have made using Git a much better experience, that I wish I had when I first started with Git.

Learn Git

Sounds silly, but distributed version control systems are much better used when you actually learn how to use them properly.  DVCS is NOT SVN, TFS, VSS or any of the other centralized VCS.  The workflow is different, the concepts are different, the tools are different.  If you use a DVCS like you use SVN or TFS, you’ll likely either be frustrated or merely enjoy better merging.

Some great resources for git include:

• The Pro Git book (online or print)
• Git Ready
• TekPub Mastering Git series
• Git for Windows Developers <- Start here for installing Git on Windows
• GitHub help
• git help <command> (from Git bash)

Join GitHub

GitHub provides such a fantastic user experience, it’s the reason why many folks choose Git.  In fact, it’s pretty hard to introduce anyone to Git without talking about GitHub.  So head over there:

http://github.com/

And create an account.  GitHub is all about collaboration, so their entire experience is centered around you, instead of projects.  You can create a free account, fork an existing project, clone, and start fooling around with other folks’ projects, but on your own sandbox so you don’t have to worry about messing anything up.  Lots of great OSS tools are already on GitHub, including:

• AutoMapper
• StructureMap
• FubuMVC
• MvcTurbine
• Fluent NHibernate
• SubSonic

And many more, just check out the github page on the C# projects.

Visualize the repository

The biggest hurdle for me personally learning Git was the difference between Git and SVN.  Things like branches, HEAD and so on are much easier just to visualize.  I Iike to use Git Extensions personally to view history, but Git comes with a tool (gitk) that can visualize as well.

Whenever I use a DVCS, Git or Hg, I keep a repository viewer up at ALL times, because I want to know exactly where I am, where I’ve been and where I want to go.  Here’s the StructureMap timeline:

This timeline’s not that interesting looking, mostly because I don’t have any local branches AND the StructureMap folks know how to keep a clean timeline.  More on that in a second.

I like Git Extensions as it shows not only history in my timeline, but the entire repository, including branches not merged back, commits in the future (if I’ve moved HEAD backwards), and just looks a little cleaner than gitk.

Don’t start with TortoiseGit

TortoiseGit is a fantastic tool for Git beginners for completely warping and destroying their Git experience.  For those coming over from SVN (as I was), it tends to be TOO familiar, and lends itself to reinforcing the SVN workflow.

I don’t like TortoiseGit because it tends to batch together several Git commands without being very explicit about this.  It emulates common SVN commands, which don’t really have an analog in Git, and generally winds up screwing things up and making things hard when they really shouldn’t be.

Instead, stick with the command-line interface to learn the right commands.  Once you’ve mastered your workflow with Git commands directly, only then should you put a UI on top that hides what’s going on underneath.

Always work in a local branch

The only time I commit to the mainline branch is for a merge or rebase.  Everything else, I work in a local branch.

Why?

For one, if you’re not the only one pushing changes, it’s a LOT easier to deal with merges in a branch than have things immediately run into merge conflicts locally from a pull.  If you work in a local branch, pulling changes down doesn’t affect your existing work.  Instead, YOU decide when to merge changes.

When I worked with branches in SVN, I actually didn’t need to change how I worked.  I already merged trunk to branch, then branch back to trunk.  I work with Git the same way, except that my branch is local, and I prefer rebase.

Prefer rebase over merge

Once you understand commits, branches and HEAD, understanding what a rebase is becomes much easier.  Instead of merging changes, which batches up a whole bunch of commits into one big diff, a rebase replays commits onto another branch.  This preserves a timeline, and is also why you see a clean history in the screen above.

I won’t go in to ALL the reasons why rebase is better, you can find this post on the case for rebase.  What I like is:

• A clean history
• The ability to revert individual commits

If everything gets batched up in a single merge commit, it’s really hard to wind back a single commit from a merge, which I have needed to do from time to time.

Don’t be afraid to reach out

Unlike some other technical communities, I’ve never felt ridiculed or insulted because I didn’t know how to do something in Git.  Git folks tend to be both passionate and knowledgeable, and want to share that passion as opposed to proving how smart they are.  Ask a question on twitter about Git, you’re sure to get several replies back.

Git is definitely a leap from SVN, but its power and flexibility are well worth the learning curve.  With Git, you’re dealing less with a version control system than a system for YOU to decide on how to do version control.  For me, I enjoy being able to make those choices.

Today I pushed out the 1.1 release of AutoMapper.  From the release notes:

Features

• Adding support for Silverlight 3.0
• Auto-implementing INotifyPropertyChanged
• Conditional member mapping
• Destination member prefixes, postfixes and naming transformers

Enhancements

• Nullable destination types more obvious
• Late binding configuration
• More members made public
• Support generic ICollection
• Enums match on value or name

Bugs

• Formatting null values
• Undefined enum values not getting mapped
• Configuration validation around missing members
• Profile resolution
• ForAllMembers skipped missing members
• Interface mapping overwritten
• Inheritance chain now evaluated by default

Head over to the AutoMapper project site to download the latest version.

The big change for 1.1 is that Silverlight 3.0 is now officially supported.  I was able to support all of the features of regular AutoMapper, except for a few pieces that just don’t exist in Silverlight, such as IDataReader etc.  Also, I moved the source to GitHub from Google Code, which has made my life much, much easier for dealing with new features, bugs, issues and releases.  Enjoy!

On a recent, very large project, we started to notice a distinct trend in our controllers.  All of our “POST” actions started to look very similar.  Check form validation, run business rule validation.  If validation succeeds, execute the actual business logic.  If it fails, just show the view with the original form.

The problem we ran into was how to encapsulate this common behavior.  We first went with some abomination of a base, CRUD controller.  I should have listened to the OO luminaries, “Favor composition over inheritance”.

Our solution was to instead capture the common paths in a custom ActionResult, passing in the pieces of behavior that change into our ActionResult.  The outcome was that we needed a way to inject services into our action results.  The ExecuteResult method needed external services, which needed to be injected.

But that brought us to one of the fundamental problems with the design of an ActionResult.  If you examine its responsibilities, it comes down to two things:

• WHAT to do
• HOW to do it

Unfortunately for us, these two responsibilities are intertwined on ActionResult.  For example, in the ViewResult object, I set up the ViewName to render and so on.  This makes it great for testing purposes, I only need to test the WHAT for controller actions.

However, the HOW for ActionResults usually winds up opening a huge can o’ worms.  Taking ViewResult, the ExecuteResult method has a metric ton of behavior around it, choosing a view engine, finding the view, rendering the view and so on.  Quite a lot for an object that just had a ViewName property on it.

We could go the route of filters, and perform property injection for the pieces needed in the ExecuteResult method.  But property injection is mostly a hack, and should only be reserved in extreme cases.

Instead, I’ll take a route similar to the “Better Action Result” post, and clearly separate the WHAT of an action result from the HOW.  The result solidifies the controller’s responsibility as a traffic controller, solely directing traffic.

The WHAT: an action method result

What I’m shooting for here is a POCO action method result.  It has zero behavior, and only holds a representation of what I want to happen as the result of an action.  If you took all of the existing action results and subtracted their “ExecuteResult” method, this is what I’m going for.

To make it sane, I’ll just create a new representation of an action method result in the form of a marker interface.  Although it’s not completely POCO, a marker interface helps later on when integrating into the ControllerActionInvoker pipeline:

public interface IActionMethodResult
{
}

Those wanting to create custom action method results just need to implement this interface, and add any data in the implementing class.

The HOW: an action method result invoker

These custom action method results will still basically build up the regular action results.  They will do whatever custom logic, and return an action result that will be consumed as normal by the MVC pipeline.  The reasoning here is that all the custom action results I’ve ever needed to build always built up the existing action results.  Staying with the eventual result of an ActionResult also lets me keep the concept of the ResultFilters in place.

Our action method result invoker will then take in an action method result, and return an ActionResult:

public interface IActionMethodResultInvoker<T>
    where T : IActionMethodResult
{
    ActionResult Invoke(T actionMethodResult, ControllerContext context);
}

public interface IActionMethodResultInvoker
{
    ActionResult Invoke(object actionMethodResult, ControllerContext context);
}

I defined two invokers, simple because it’s easier to perform the generic conversions of what’s all object-based to one that’s generic-based, through a simple facade:

public class ActionMethodResultInvokerFacade<T> 
    : IActionMethodResultInvoker 
    where T : IActionMethodResult
{
    private readonly IActionMethodResultInvoker<T> _invoker;

    public ActionMethodResultInvokerFacade(IActionMethodResultInvoker<T> invoker)
    {
        _invoker = invoker;
    }

    public ActionResult Invoke(object actionMethodResult, ControllerContext context)
    {
        return _invoker.Invoke((T) actionMethodResult, context);
    }
}

Implementers of an action method result invoker can use the generic interface, where I’ll wrap that generic version with a non-generic one and do the casting myself.

Finally, I need to override the CreateActionResult method in our custom action invoker:

protected override ActionResult CreateActionResult(
    ControllerContext controllerContext, 
    ActionDescriptor actionDescriptor, 
    object actionReturnValue)
{
    if (actionReturnValue is IActionMethodResult)
    {
        var openWrappedType = typeof(ActionMethodResultInvokerFacade<>);
        var actionMethodResultType = actionReturnValue.GetType();
        var wrappedResultType = openWrappedType.MakeGenericType(actionMethodResultType);

        var invokerFacade = (IActionMethodResultInvoker) _container.GetInstance(wrappedResultType);

        var result = invokerFacade.Invoke(actionReturnValue, controllerContext);

        return result;
    }
    return base.CreateActionResult(controllerContext, actionDescriptor, actionReturnValue);
}

Based on the action return value, I check to see if it’s an instance of our marker interface.  If so, I’ll then construct the closed generic type of our invoker facade.  This facade lets me call an “Invoke” method that accepts something of type “object”, instead of the “T” of the generic action method invoker interface.

Once I create the closed type of the invoker facade, I use the container to create an instance of this facade type.  Since the facade also depends on the generic invoker, I’ll get the real invoker as well.  Finally, I call the Invoke method, passing in the action return value (an IActionMethodResult), and return the result of that.

Example: Executing commands

Now that I have an entry point for setting up external invokers that don’t have to rely on hokey property injection, or worse, service location, I can start to do really interesting invocation patterns in our controller actions.  As I alluded earlier, our POST actions had the same pattern over and over again.  I can now capture this in an action method result:

public class CommandMethodResult<TModel> : IActionMethodResult
{
    public CommandMethodResult(TModel model,
        Func<ActionResult> successContinuation,
        Func<ActionResult> failureContinuation)
    {
        Model = model;
        SuccessContinuation = successContinuation;
        FailureContinuation = failureContinuation;
    }

    public TModel Model { get; private set; }
    public Func<ActionResult> SuccessContinuation { get; private set; }
    public Func<ActionResult> FailureContinuation { get; private set; }
}

This action method result represents the model of handling the form, plus what to on success and what to do on failure.  The handler of this action method result can then contain the common path of validation, execution and success/failure:

public class CommandMethodResultInvoker<TModel> 
    : IActionMethodResultInvoker<CommandMethodResult<TModel>> 
{
    private readonly ICommandMessageHandler<TModel> _handler;

    public CommandMethodResultInvoker(ICommandMessageHandler<TModel> handler)
    {
        _handler = handler;
    }

    public ActionResult Invoke(
        CommandMethodResult<TModel> actionMethodResult, 
        ControllerContext context)
    {
        if (!context.Controller.ViewData.ModelState.IsValid)
        {
            return actionMethodResult.FailureContinuation();
        }

        _handler.Handle(actionMethodResult.Model);

        return actionMethodResult.SuccessContinuation();
    }
}

In the Invoke action, I first check to see if there are any validation errors.  If so, then I’ll just return the failure result continuation (that Func<ActionResult>).  It’s just a callback to the originating action on how to build up the failure ActionResult.

If there are no validation errors, then I hand off the form to an individual handler, an ICommandMessageHandler<T> that is responsible for *only* executing the success path of a POST.  Finally, I execute the SuccessContinuation callback, and return the result of that.  The command message handler is a rather simple interface:

public interface ICommandMessageHandler<T>
{
    void Handle(T message);
}

In this handler, I’ll have all the logic, services, etc. needed to process this form.  Because I’m only responsible for the success path here, you won’t see any mixed responsibilities of creating ActionResults, checking ModelState and so on.  To make it easier to build up the action method result, I’ll create a helper method on our controller layer supertype class:

protected CommandMethodResult<T> Command<T>(
    T model, 
    Func<ActionResult> successContinuation)
{
    return new CommandMethodResult<T>(
        model, 
        successContinuation, 
        () => View(model));
}

Since the default of a failure action is just to show the same view with the same model, I pass that in as the default.  Our controller action for POST then becomes very, very thin:

[HttpPost]
public CommandMethodResult<FooEditModel> Edit(FooEditModel form)
{
    return Command(form, () => RedirectToAction("Index"));
}

One line!  Testing this action also becomes a breeze, as I don’t need to set up some crazy failure/success paths, I only need to test the model property and the success/failure continuations in isolation.  Finally, our handler for the form can do whatever it needs:

public class FooEditModelHandler : ICommandMessageHandler<FooEditModel>
{
    private readonly IFooService _service;

    public FooEditModelHandler(IFooService service)
    {
        _service = service;
    }

    public void Handle(FooEditModel message)
    {
        // handle this edit model somehow
    }
}

Because my handler has no responsibilities around ModelState, ViewData, ActionResults or anything else of that nature, it becomes very tightly focused and easy to maintain.

Finally, I need to configure StructureMap for all this new generic wiring:

Scan(scanner =>
{
    scanner.TheCallingAssembly();
    scanner.WithDefaultConventions();
    scanner.ConnectImplementationsToTypesClosing(typeof (IActionMethodResultInvoker<>));
    scanner.ConnectImplementationsToTypesClosing(typeof (ICommandMessageHandler<>));
    scanner.Convention<CommandMessageConvention>();
});

I connect all closed implementations of the invokers and handlers, as well as add a custom convention to connection the pieces needed for the IActionMethodResultInvoker<CommandMethodResult<TModel>> interface to the CommandMethodResultInvoker<TModel> implementation:

public class CommandMessageConvention : IRegistrationConvention
{
    public void Process(Type type, Registry registry)
    {
        if (type.ImplementsInterfaceTemplate(typeof(ICommandMessageHandler<>)))
        {
            var interfaceType = type.FindFirstInterfaceThatCloses(typeof (ICommandMessageHandler<>));
            var commandMessageType = interfaceType.GetGenericArguments()[0];
            
            var openCommandMethodResultType = typeof (CommandMethodResult<>);
            var closedCommandMethodResultType = openCommandMethodResultType.MakeGenericType(commandMessageType);

            var openActionMethodInvokerType = typeof (IActionMethodResultInvoker<>);
            var closedActionMethodInvokerType =
                openActionMethodInvokerType.MakeGenericType(closedCommandMethodResultType);

            var openCommandMethodResultInvokerType = typeof (CommandMethodResultInvoker<>);
            var closedCommandMethodResultInvokerType =
                openCommandMethodResultInvokerType.MakeGenericType(commandMessageType);

            registry.For(closedActionMethodInvokerType).Use(closedCommandMethodResultInvokerType);
        }
    }
}

That last piece is a little crazy, but it can sometimes be a bit annoying to deal with open and closed generics with the reflection API.

Wrapping it up

One of my biggest pet peeves in the MVC framework is the places where the WHAT is combined with the HOW.  Filters and action results are two of these places.  With filters, I opted for property injection to supply the needed services.  With action results, I instead chose to separate those concerns.

The result is a much cleaner and extensible abstraction.  I can modify the HOW of an action method result, without modifying the classes responsible for the WHAT.  The action method results stay POCO, and the action method result invokers can get as complex as need be, but with the added power of dependency injection.  My invokers can depend on whatever services they need to function, all completely orthogonal to pieces built from my controller actions.

So far, we’ve looked at extending the advantages of dependency injection to our controllers and its various services.  We started with a basic controller factory that merely instantiates controllers to one that takes advantage of the modern container feature of nested/child containers to provide contextual, scoped injection of services.  With a child container, we can do things like scope a unit of work to a request, without needing to resort to an IHttpModule (and funky service location issues).

Having the nested container in place gives us a nice entry point for additional services that the base controller class builds up, including filters.  Right after controllers, filters are one of the earliest extension points of ASP.NET MVC that we run into where we want to start injecting dependencies.

However, we quickly run into a bit of a problem.  Out of the box, filters in ASP.NET MVC are instances of attributes.  That means that we have absolutely no hook at all into the creation of our filter classes.  If we have a filter that uses a logger implementation:

public class LogErrorAttribute : FilterAttribute, IExceptionFilter
{
    private readonly ILogger _logger;

    public LogErrorAttribute(ILogger logger)
    {
        _logger = logger;
    }

We’ll quickly find that our code using the attribute won’t compile.  You then begin to see some rather heinous use of poor man’s dependency injection to fill the dependencies.  But we can do better, we can keep our dependencies inverted, without resorting to various flavors of service location or, even worse, poor man’s DI.

Building Up Filters

We’ve already established that we do not have a window into the instantiation of filter attributes.  Unless we come up with an entirely new way of configuring filters for controllers that doesn’t involve attributes, we still need a way to supply dependencies to already-built-up instances.  Luckily for us, modern IoC containers already support this ability.

Instead of constructor injection for our filter attribute instance, we’ll use property injection instead:

public class LogErrorAttribute : FilterAttribute, IExceptionFilter
{
    public ILogger Logger { get; set; }

    public void OnException(ExceptionContext filterContext)
    {
        var controllerName = filterContext.Controller.GetType().Name;
        var message = string.Format("Controller {0} generated an error.", controllerName);

        Logger.LogError(filterContext.Exception, message);
    }
}

The LogErrorAttribute’s dependencies are exposed as properties, instead of through the constructor.  Normally, I don’t like doing this.  Property injection is usually reserved for optional dependencies, backed by the null object pattern.  In our case, we don’t really have many choices.  To get access to the piece in the pipeline that deals with filters, we’ll need to extend some behavior in the default ControllerActionInvoker:

public class InjectingActionInvoker : ControllerActionInvoker
{
    private readonly IContainer _container;

    public InjectingActionInvoker(IContainer container)
    {
        _container = container;
    }

    protected override FilterInfo GetFilters(
        ControllerContext controllerContext, 
        ActionDescriptor actionDescriptor)
    {
        var info = base.GetFilters(controllerContext, actionDescriptor);

        info.AuthorizationFilters.ForEach(_container.BuildUp);
        info.ActionFilters.ForEach(_container.BuildUp);
        info.ResultFilters.ForEach(_container.BuildUp);
        info.ExceptionFilters.ForEach(_container.BuildUp);

        return info;
    }
}

In our new injecting action invoker, we’ll first want to take a dependency on an IContainer.  This is the piece we’ll use to build up our filters.  Next, we override the GetFilters method.  We call the base method first, as we don’t want to change how the ControllerActionInvoker locates filters.  Instead, we’ll go through each of the kinds of filters, calling our container’s BuildUp method.

The BuildUp method in StructureMap takes an already-constructed object and performs setter injection to push in configured dependencies into that object.  We still need to manually configure the services to be injected, however.  StructureMap will only use property injection on explicitly configured types, and won’t try just to fill everything it finds.  Our new StructureMap registration code becomes:

For<IActionInvoker>().Use<InjectingActionInvoker>();
For<ITempDataProvider>().Use<SessionStateTempDataProvider>();
For<RouteCollection>().Use(RouteTable.Routes);

SetAllProperties(c =>
{
    c.OfType<IActionInvoker>();
    c.OfType<ITempDataProvider>();
    c.WithAnyTypeFromNamespaceContainingType<LogErrorAttribute>();
});

We made two critical changes here.  First, we now configure the IActionInvoker to use our InjectingActionInvoker.  Next, we configure the SetAllProperties block to include any type in the namespace containing our LogErrorAttribute.  We can then add all of our custom filters to the same namespace, and they will automatically be injected.

Typically, we have a few namespaces that our services are contained, so we don’t have to keep configuring this block too often.  Unfortunately, StructureMap can’t distinguish between regular attribute properties and services, so we have to be explicit in what StructureMap should fill.

The other cool thing about our previous work with controller injection is that we don’t need to modify our controllers to get a new action invoker in place.  Instead, we work with our normal DI framework, and the controller is unaware of how the IActionInvoker gets resolved, or which specific implementation is used.

Additionally, since our nested container is what’s resolved in our InjectedActionInvoker (StructureMap automatically resolves IContainer to itself, including in nested containers), we can use all of our contextual items in our filters.  Although I would have preferred to use constructor injection on my filters, this design is a workable compromise that doesn’t force me to resort to less-than-ideal patterns such as global registries, factories, service location, or poor man’s DI.