Question

We are using Linq to SQL to read and write our domain objects to a SQL Server database.

We are exposing a number of services (via WCF) to do various operations. Conecptually, the implementation of these operations consists of three steps: reconstitute the necessary domain objects from the database; execute the operation on the domain objects; persist the (now changed) domain objects back to the database.

Problem is that sometimes, there are two or more instances of the same entity objects, which can lead to inconsistenties when saving the objects back to the db. A little made-up example:

public void Move(string sourceLocationid, destinationLocationId, itemId);

which is supposed to move the item with the given id from the source to the destination location (actual services are more complicated, often involving many locations, items etc). Now, it could be that both source and destination location id are the same – a naive implementation would just reconstitute two instances of the entity object, which would lead to problems.

This issue is now “solved” by checking for it manually, i.e. we reconstitute a first location, check if the id of the second is different from it, and if so reconsistute the second, and so on. This is obvisouly difficult and error-prone.

Anyway, I was actually surprised that there does not seem to be a “standard” solution for this in domain driven design. In particular, repositories or factories do not seem to solve this problem (unless they maintain their own cache, which then needs to be updated etc).

My idea would be to make a DomainContext object per operation, which tracks and caches the domain objects used in that particular method. Instead of reconstituing and saving individual domain objects, such an object would be reconstituted and saved as a whole (possibly using repositories), and it could act as a cache for the domain objects used in that particular operation.

Anyway, it seems that this is a common problem, so how is this usually dealt with? What do you think of the idea above?

Answer 1

The DataContext in Linq-To-Sql supports the Identity Map concept out of the box and should be caching the objects you retrieve. The objects will only be different if you are not using the same DataContext for each GetById() operation.

Linq to Sql objects aren’t really valid outside of the lifetime of the DataContext. You may find Rick Strahl’s Linq to SQL DataContext Lifetime Management a good background read.

Also, the ORM is not responsible for logic in the domain. It’s not going to disallow your example Move operation. That’s up for the domain to decide what that means. Does it ignore it? or is it an error? It’s your domain logic, and that needs to be implemented at the service boundary you are creating.

However, Linq-To-Sql does know when an object changes, and from what I’ve looked at, it won’t record the change if you are re-assigning the same value. e.g. if Item.LocationID = 12, setting the locationID to 12 again won’t trigger an update when SubmitChanges() is called.

Based on the example given, I’d be tempted to return early without ever loading an object if the source and destination are the same.

public void Move(string sourceLocationId, destinationLocationId, itemId)
{
    if( sourceLocationId == destinationLocationId )
        return;

    using( DataContext ctx = new DataContext() )
    {
       Item item = ctx.Items.First( o => o.ItemID == itemId );
       Location destination = 
          ctx.Locations.First( o => o.LocationID == destinationLocationID );
       item.Location = destination;

       ctx.SubmitChanges();
    }
}

---

Another small point, which may or may not be applicable, is you should make your interfaces as chunky as possible. e.g. If you’re typically going to perform 10 move operations at once, it’s better to call 1 service method to perform all 10 operations at once, rather than 1 operation at a time. ref: chunky vs chatty