[UnitOfWork]

public virtual void Upload(DocumentDto dto)

{

    var entity = new Document().Merge(dto);

    using (var stream = new MemoryStream(dto.Data))

    {

        repository.Save(entity, stream);

    }

}

After doing some performance profiling, it quickly popped up as the top offender. Why? Because it’s holding a database transaction open while saving a file. In order to fix it, we have to ditch our UnitOfWork aspect and implement a finer-grained transaction. Basically what needs to happen is saving the entity and saving the file need to be separate operations so we can commit the transaction as soon as the entity is saved. And since saving the file could fail, we might have to clean up an orphaned file entity.

public virtual void Upload(DocumentDto dto)

{

    var entity = new Document().Merge(dto);

    SaveEntity(entity);

    try

    {

        SaveFile(entity, dto.Data);

    }

    catch

    {

        TryDeleteEntity(entity);

        throw;

    }

}

private void SaveEntity(Document entity)

{

    unitOfWork.Start();

    try

    {

        repository.Save(entity);

        unitOfWork.Commit();

    }

    catch

    {

        unitOfWork.Rollback();

        throw;

    }

}

private void SaveFile(Document entity, byte[] data)

{

    using (var stream = new MemoryStream(data))

    {

        repository.Save(entity, stream);

    }

}

private void TryDeleteEntity(Document entity)

{

    unitOfWork.Start();

    try

    {

        repository.Delete(entity);

        unitOfWork.Commit();

    }

    catch

    {

        unitOfWork.Rollback();

    }

}

That wasn’t too bad except that the number of lines of code exploded and we have a few private methods in our service that only deal with plumbing. It would be nice to push them into the framework. Since C# is awesome, we can use a combination of delegates and extension methods to do that.

public virtual void Upload(DocumentDto dto)

{

    var entity = new Document().Merge(dto);

    unitOfWork.Execute(() => repository.Save(entity));

    try

    {

        repository.SaveFile(entity, dto.Data);

    }

    catch

    {

        unitOfWork.TryExecute(() => repository.Delete(entity));

        throw;

    }

}

public static class DocumentRepositoryExtensions

{

    public static void SaveFile(this IDocumentRepository repository, Document document, byte[] data)

    {

        using (var stream = new MemoryStream(data))

        {

            repository.SaveFile(document, stream);

        }

    }

}

public static class UnitOfWorkExtensions

{

    public static void Execute(this IUnitOfWork unitOfWork, Action action)

    {

        unitOfWork.Start();

        try

        {

            action.Invoke();

            unitOfWork.Commit();

        }

        catch

        {

            unitOfWork.Rollback();

            throw;

        }

    }

    public static void TryExecute(this IUnitOfWork unitOfWork, Action action)

    {

        unitOfWork.Start();

        try

        {

            action.Invoke();

            unitOfWork.Commit();

        }

        catch

        {

            unitOfWork.Rollback();

        }

    }

}

Now we can move the extension methods into the framework and out of our service. In a less awesome language we could define these convenience methods on the IUnitOfWork interface and implement them in an abstract base class, but inheritance is evil and it’s a tradeoff we don’t have to make in C#.

public UserIndexViewModel GetIndexViewModel(int pageSize, int pageNumber) {
    var model = new UserIndexViewModel();

    var allUsers = Session.CreateCriteria<User>();

    model.Total = CriteriaTransformer
        .TransformToRowCount(allUsers)
        .UniqueResult<int>();

    model.Users = allUsers
        .SetFirstResult(pageSize * (pageNumber - 1) + 1)
        .SetMaxResults(pageSize)
        .AddOrder<User>(u => u.LastName, Order.Asc)
        .List<User>();

    return model;
}

There isn’t much going on here, but it could be better. I’m looking at the arguments pageSize and pageNumber. Notice how they both start with the prefix “page”. That’s a smell. The common prefix means the arguments are related, so let’s apply the Introduce Parameter Object refactoring and see what happens.

public class Page {
    private readonly int number;
    private readonly int size;

    public Page(int number, int size) {
        this.number = number;
        this.size = size;
    }

    public int Size {
        get { return size; }
    }

    public int Number {
        get { return number; }
    }

    public int FirstResult {
        get { return size * (number - 1) + 1; }
    }
}

What did we accomplish?

• Creating the parameter object gave us a place to put the logic of calculating the first result of the current page. This logic would otherwise be scattered around the application and even though it’s simple, it’s error prone.
• The logic of calculating the first result is testable.

[Test]
public void Should_calculate_first_result_of_current_page() {
    Assert.That(new Page(1, 20).FirstResult, Is.EqualTo(1));
    Assert.That(new Page(2, 20).FirstResult, Is.EqualTo(21));
    Assert.That(new Page(3, 20).FirstResult, Is.EqualTo(41));
}

It’s not rocket science, but it still deserves a test. Our other option is spinning up Cassini and clicking around to make sure we got it right. That’s just silly. A little piece of me dies each time I press F5 to run a manual test.

Anyway, there is this thing that happens with single responsibility classes. Because their purpose is crisp, it draws out robustness. In this case, I’m thinking about what we should we do if we get zero or a negative value for page number. I’m a fail fast kind of guy, so I’d probably go with a guard clause.

public Page(int number, int size) {
    GuardAgainstLessThanOne(number);
    ...
}

But you could silently correct it if that’s how you roll:

public int Number {
    get { return Math.Max(1, number); }
}

The point is that this is an obvious scenario to consider when looking at such a special purpose object. All too often though, bits of logic are mixed together like 32 kindergarteners sitting next to each other on a rug during a lesson. The room is one fart or tickle away from erupting into total kaos. It’s roughly half teaching and half crowd control, only without the rubber bullets and pepper spray. Not surprisingly, overcrowded classrooms don’t work that well and over-ambitous functions don’t work that well either. Each little bit of logic needs some one on one with you. Give it a chance to be all it can be by pulling it aside and getting to know it a little better. You might be surprised.

Recently, the stake holders came up with a twist that went something like this: If the order contains a gift card, add the contact to a specific folder in the CRM application. No big deal, we had a nicely abstracted OrderGateway interface and I was already envisioning a quick addition to the existing decorator chain.

class OrderWithGiftCardGateway extends OrderGatewayDecorator
{
    ...

    public function createOrder(CreateOrderRequest $order)
    {
        if ($this->containsGiftCard($order))
        {
            $this->addContactToFolder($order);
        }

        return parent::createOrder($order);
    }
}

I had a few minutiae questions like what happens with duplicates, etc. It took me nearly an hour to track down the right person and get real answers. During the conversation, a subtle comment was made that I almost missed.

Stake holder: We should check with the product supplier to make sure the gift card sku I made up isn’t for a real product.

Me: Say what?

Stake holder: The gift card is not fulfilled by the product supplier, it’s fulfilled by the affiliate.

Me: %$@!&, I’m glad we had this conversation.

We talked about what it meant for the the affiliate to fulfill the product and basically the folder stuff was okay, but I recommended we remove the fake sku from the order before sending it through.

public function createOrder(CreateOrderRequest $order)
{
    if ($this->containsGiftCard($order))
    {
        $this->addContactToFolder($order);
        $this->removeGiftCardFromOrder($order);
    }

    return parent::createOrder($order);
}

I didn’t have a buddy to pair with so I just grabbed Keith for a minute at the end of the day to walk through things. I recapped the stake holder discussion and we looked through the code. He pointed out I was missing the concept of fulfillment and that was hard earned knowledge that would be lost!

public function createOrder(CreateOrderRequest $order)
{
    if ($this->containsGiftCard($order))
    {
        $this->sendToAffiliateForFulfillment($order);
        $this->removeGiftCardFromOrder($order);
    }

    return parent::createOrder($order);
}

That was huge. – Paris Hilton

Why was that huge? Because it changed the conversation. Right away we thought of important requirements like this should be in a transaction with the order and the template email the affiliate gets should include the customer’s address, etc.

It tells an important story for the next guy looking at the code and it changes the role of the programmer from code monkey to business partner. Maybe you think I’m crazy, but this stuff matters to me.

Martinizing is similar to refactoring in that it does not change the observable behavior of the code, but the goal is different. When I refactor, I am changing the design, usually in an effort to add a new feature in an open closed manner.

When I martinize, I am telling a story. The most important story being the desired behavior, but also a story of the hard earned knowledge acquired along the way. If I spend hours distilling some business concept. I want to leave a trail for the next guy to understand that a simple property assignment or conditional statement isn’t so simple. And of course the perfect way to punctuate that message is with a well written unit test.