Andrew Peters’ Blog

Rowan’s post 28x ties back nicely to the language debate earlier in the week.

You see, in my mind there’s a relationship between some of the traits I look for in a good developer and their language of choice.

Please bear in mind these are only my opinions based on my experience. You likely value different things so your mileage may vary.

The BackgroundMotion community site and ASP.NET code sample that we worked with Microsoft to develop has gone live. w00t!

If you’re interested in ASP.NET you definitely want to check out the sample as it illustrates one approach to architecting .NET web apps. The architecture was really designed to facilitate rapid development so emphasizes things like testability etc. My personal highlights of the sample are:

• Use of a domain-driven design techniques. Repository and Unit of Work abstractions over LINQ to SQL
• Model-level validation using the Validation Block
• Dependency injection using Composite Web Block
• Using Lucene.NET to index a domain model
• Using MVP with declarative data-binding in the presentation layer

Let us know what you think.

Ambler nicely articulates in The consequences of fixed-price IT projects the fundamental problem facing IT services companies.

Basically, the problem boils down to an impedance mismatch between the traditional customer/vendor dance on the one hand and modern software development methods (agile) on the other.

My feeling is that IT services shops should use variable-priced contracts as a competitive advantage! Why? Because as Ambler points out, more often than not, fixed price projects are a mess. I’ve seen this first-hand and it seems particularly endemic in the New Zealand market. Such projects lead to, among other things:

• Angry/disappointed/frustrated customers as the price goes up late in the delivery, or when the delivered system sucks.
• Low staff moral as they are left to pick up the pieces (read long hours.)
• Developer frustration as attempts to bring in agile methods are mostly futile when working in a fixed-price setup.
• Propagation of the fixed-price vicious cycle. The customer was burnt last time so this time the contract will need to be even more bullet-proof.
• Increased risk for all stake-holders! The vendor has no idea what they are building or how much it will really cost - even though they have committed to both in a contract! The customer has signed up to get a system that may not meet their requirements and will most likely cost more than they expect. When these cost overruns come near the end of delivery, they are virtually impossible to walk away from. Some despicable vendors actually leverage this approach to make more money. i.e “That sounds like a change request and it sounds expensive.”

So what would I do if I were running a services company?

Embrace contracts based on “variable-priced projects with gated investment based on interim deliverables (ideally working software.)” Sure, some customers will require education and some deals will just have to be walked away from. But over time, constantly delivering better software, more quickly and with less risk is just too compelling and word gets around. I have no doubt that the first service shops that can successfully adopt this strategy will win.

One of the issues with current implementations of the Repository pattern is that ORM specific details can leak into the Repository interface. Most commonly this takes the form of concrete ORM querying machinery such as Query Objects, Expressions or custom object query languages. This weakening of the Repository abstraction is undesirable because it can make it more difficult to use our Repositories in different ways. For example using a fake repository to speed up our unit tests.

Enter LINQ. With language-level support for building expressions, we can now shore up our Repository interface in a completely abstract way. Our query expressions are simply handed off to the appropriate LINQ-provider which does the heavy-lifting for us. Even better, normal collections can be queried using LINQ and so implementing trivial in-memory fake repositories is dead easy. We used this approach on BackgroundMotion and it worked pretty well. Here’s what some of the code looks like:

// our Repository contract...
 
public interface IRepository<T>
  where T : IIdentifiable
{
  int Count();
  int Count(Expression<Func<T, bool>> expression);
 
  void Add(T entity);
  void Remove(T entity);
  void Save(T entity);
 
  T FindOne(int id);
  T FindOne(Expression<Func<T, bool>> expression);
 
  bool TryFindOne(Expression<Func<T, bool>> expression, out T entity);
 
  IList<T> FindAll();
  IList<T> FindAll(Expression<Func<T, bool>> expression);
 
  IQueryable<T> Find();
  IQueryable<T> Find(int id);
  IQueryable<T> Find(Expression<Func<T, bool>> expression);
}
 
// and this is how we used our real Repository implementation
 
Repository<Contribution>
  .Find(c => c.ApprovedById == null);
 
// or...
 
Repository<Tag>
  .Find()
  .OrderBy(t => t.Value)
  .Take(Constants.PageSize)
  .ToList();

Using this approach we were able to implement a fake Repository that used simple collections internally and just worked.

Good times. :-)

Ayende just posted about dynamic LINQ queries and how not to write them.

On BackgroundMotion we were using Linq to SQL and needed the Contains operator. Unfortunately, on the CTP we were using the Contains operator wasn’t implemented by the Linq to SQL provider. Happily however, we were able to emulate it by dynamically building the required query. Here is the code:

public static class LinqContainsPredicateBuilder
{
  public static Expression<Func<T, bool>> Build<T, S>(ICollection<S> collection, string targetProperty)
  {
    Invariant.ArgumentNotEmpty(collection, "collection");
    Invariant.ArgumentNotEmpty(targetProperty, "targetProperty");
 
    Expression completeExpression = null;
    ParameterExpression parameterExpression = Expression.Parameter(typeof(T), "t");
 
    foreach (S item in collection)
    {
      Expression nextExpression = Expression.EQ
        (
        Expression.Property(parameterExpression, typeof(T).GetProperty(targetProperty)),
        Expression.Constant(item)
        );
 
      completeExpression = (completeExpression != null)
        ? Expression.OrElse(completeExpression, nextExpression)
        : nextExpression;
    }
 
    return (Expression<Func<T, bool>>)QueryExpression.Lambda(completeExpression, parameterExpression);
  }
}

For example, let’s say we are interested in finding all the Tag objects in the repository corresponding to a list of tags entered by a user. We could do this like so:

IList<string> candidateTags = new List<string>();
 
candidateTags.Add("Foo");
candidateTags.Add("Bar");
candidateTags.Add("Baz");
 
Expression<Func<T, bool>> expr
  = LinqContainsPredicateBuilder.Build<Tag, string>(candidateTags , "Value");
 
// now use the expression in a LINQ query...

This code will return any Tag objects that have a Value property matching any of the elements in the candidateTags list.

Being able to do this kind of thing is powerful and compelling feature of LINQ.