delegate(Product p1, Product p2){ return p1.Code.CompareTo(p2.Code); }

vs.

(p1, p2)=> p1.Code.CompareTo(p2.Code);

BTW, You could make IDomainContext implement IWith. Then you could return that instance from your With property and get rid of the helper class.

Fluenty things often involve a compromise in terms of design purity. It’s a tradeoff.

You can move the With property onto a layer supertype to clean up the dryness (since service layer classes manage transactions), but that’s a tradeoff on the DI side, since constructor injection in a base class is messy.

If you want to see a similar design, you can see Fowler’s writeup on the Notification Pattern. His usage of failIfNullOrBlank() on the layer supertype is IMO a very similar design (as the With), but without delegates of course.

http://martinfowler.com/eaaDev/Notification.html

@Chad

I haven’t moved to C# 3.0 land yet. I’m still in 2.0.

I do have to say that the non-lambda approach has less noi()s=>e..

Also, trying to cram a lambda where an anonymous method is natural seems a bit awkward to me.

Since this, so far in this discussion, is solely for the With.Transaction() usage, what if you just had an extension method on IDataContext:

context.WithTransaction(()=>
{
// blah blah
});

There are a couple ways. Considering transactions are typically managed by the Service Layer, you can finagle it in through there.

I’m assuming there’s some type of IContextFactory or something:

public interface IMyService
{
void DoSomething();
}

public class MyService : IMyService
{
public MyService(IDbContextFactory factory)
{
_dbFactory = factory;
}

private IDbContextFactory _dbFactory;

protected IWith With
{
get { return new WithHelper(_dbFactory.Create()); }
}

public void DoSomething()
{
With.Transaction(delegate {
//do transactional work
});
}
}

At which point you’d convert the Transaction method of my previous example into an instance member, instead of a static one.

public interface IWith
{
void Transaction(VoidDelegate work);
}

public class WithHelper : IWith
{
public WithHelper(IDbContext context)
{
_dbContext = context;
}

private IDbContext _dbContext;

public void Transaction(VoidDelegate work)
{
using (IDbTransaction tx = _dbContext.CreateTx())
{
work();
tx.Complete();
}
}
}

You can also move the With property onto an abstract layer supertype if you like. It will make constructor injection tricky though, you might look at Setter injection instead (which I don’t prefer, but it’s a choice). Also make sure you are taking advantage of IDisposable (since we are talking about resources which should be properly managed and disposed of).

You can take this same approach (using a delegate to fill a hole in the middle) to create an alternative to a Template Method. I built one recently (but not for transactions), where their was a fluent api wrapping the helper (ie..the Transaction(VoidDelegate work) returned an interface)..

In my case, It worked really well for enforcing the DRYness of some error handling code that was needed in multiple places.

@Evan: How do you get the context into the With() class and/or the Transaction() function?

With.Transaction(delegate {
//do something
});

public delegate void VoidDelegate();

public class With
{
public static void Transaction(VoidDelegate work)
{
using(ITransaction trans = context.BeginTransaction())
{
work();
trans.Complete();
}
}
}

I’m omitting the dependency stuff for context, but you should get the gist. You can do this in 2.0, or spiffy it up with 3.0 features if you like.

I’ve seen people refer to this as the Hole in the Middle pattern.