Linq to SQL & Castle IoC Container sanity check please

Question

I've just started using both Linq to SQL and Windsor Castle IoC container for a new web app and, although things seem to be working OK in preliminary tests, I could really do with a sanity check on it.

I was running into problems when I tried to pull objects out of the database using Linq in different parts of the app and then updating them in the database. As they were from different data contexts I couldn't save the changes.

So I have made a single datacontext used across the application - hopefully on a per web request basis. - Is this a reasonable way to fix the problem?

It looks like this:

public class DataContextAccessor : IDataContextAccessor
{
    private readonly DataContext dataContext;
    public DataContextAccessor(string connString)
    {
        dataContext = new DataContext(connString);
    }
    public DataContext DataContext { get { return dataContext; } }
}

I used Castle to instiantiate this like so:

  <component id="DataContextAccessor" service="DomainModel.Repositories.IDataContextAccessor, DomainModel"
                      type="DomainModel.Repositories.DataContextAccessor, DomainModel" lifestyle="PerWebRequest">
  </component>

Then whenever I want to get at the database in a class I am just declaring IDataContext datacontext in my the constructor.

• Will this (as I hope) create a single data context for each web request - and not give me any race problems when many requests are coming in at the same time?

Answer 1

The problem I can see you are going to have here is if your interface IDataContextAccessor exposes the DataContext property like this:

public interface IDataContextAccessor{
  DataContext DataContext{get;}
}

The problem with this is that you have actually tightly coupled your interface to the DataContext created by linq meaning mocking and unit testing will be near on impossible.