DI with disposable objects

Question

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

Answer 1

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.

• Sunny: 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
• supercat: The proper approach is for the code which supplies the object to tell the recipient whether it is passing ownership, or merely passing a reference to an object owned by someone else. In most cases, the calling code will know. Objects which unconditionally take ownership (e.g. StreamReader) are rude, but if the recipient of an IDisposable may be the last entity that uses it, and if the last entity to use that recipient may know nothing of the IDisposable object it contains, the recipient of the IDisposable would be the only entity that could dispose it.

Answer 2

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>();

• Sunny: So, if I understand correctly, I should wrap the DataContext as a UnitOfWork & dispose it once the unit is completed. So the repository will not dispose the DataContext. But then, if I don't want to use DI at a later stage, I will have to put this code back?
• Luhmann: 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.

Answer 3

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.

• Sunny: 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.