views:

49

answers:

3

Suppose my repository class looks like this:

class myRepository : IDisposable{
    private DataContext _context;
    public myRepository(DataContext context){
        _context = context;
    }
    public void Dispose(){ 
        // to do: implement dispose of DataContext
    }
}

now, I am using Unity to control the lifetime of my repository & the data context & configured the lifetimes as:
DataContext - singleton
myRepository - create a new instance each time

Does this mean that I should not be implementing the IDisposable on the repository to clean up the DataContext?

Any guidance on such items?

EDIT: DataContext - singleton - read this as singleton per-web request

+2  A: 

If I were you, I would either do a UnitOfWork pattern implementation instead, or let the IOC container manage the lifetime of your DataContext.

Structuremap for instance has a HttpContextScoped option, so that you register your DataContext like so:

For<DataContext>().HttpContextScoped().Use<MyDataContext>();
Luhmann
Sunny
I would let the container control it. And why would decide not to use DI at a later point, after you implemented it? Leave the DI in there, and you don't have to worry about it.
Luhmann
A: 

Does this mean that I should not be implementing the IDisposable on the repository to clean up the DataContext?

It sounds like it - from what you're saying, all repositories will share the same DataContext, but the first repository you create will dispose of it.

What creates the DataContext? Whatever that is, it should dispose of it.

Tim Robinson
I meant to say that the DataContext is created once per web request, you can consider it to be singleton in a single webrequest. I edited my question reflect this more clearly.
Sunny
+2  A: 

As a general rule, abstract dependencies should not derive from IDisposable, because it would be a Leaky Abstraction. A dependency may or may not hold unmanaged resources dependending on concrete implementation. In any case, the container should manage lifetime, so it's not up to the consumer to do so - it has no knowledge of the lifetime of the dependency: it could be shared with other consumers, in which case it would be destructive to prematurely dispose of it.

That said, a (LINQ to SQL?) DataContext represents a different problem because it already implements IDisposable, and you can't very well change this because it's defined in the BCL.

You can either properly implement IDisposable for your repository, but that means that you will have to match lifetime for all repositories and the datacontext.

The other alternative is to simply ignore that you are holding on to a disposable resource, but if you do that, you will have to make absolutely sure that Unity properly disposes of the DataContext at the appropriate time - but since you plan on using the Singleton lifetime, this shouldn't be a problem.

Mark Seemann
You are right about the "destructive to prematurely dispose" part :) While I am leaning towards ignoring the DataContext as a disposable resource, I might end up with a UnitOfWork pattern as mentioned @Luhmann
Sunny