ansaurus

Question

ServiceContainer, IoC, and disposable objects

Answer 1

+3 A:

One option might be to go with a factory pattern, so that the objects created directly by the IoC container never need to be disposed themselves, eg

IBinaryDataProviderFactory factory =
    ServiceContainer.Global.Resolve<IBinaryDataProviderFactory>();
using(IBinaryDataProvider provider = factory.CreateProvider())
{
    ...
}

Downside is added complexity, but it does mean that the container never creates anything which the developer is supposed to dispose of - it is always explicit code which does this.

If you really want to make it obvious, the factory method could be named something like CreateDisposableProvider().

Chris Ballard 2009-02-17 13:08:36

The whole point of the IoC container is that I later, through configuration, can return a different object. In your example, every such object must implement IDisposable. My question is: is that a criteria for those objects? Can I specify this criteria somewhat, or is it per-interface? Future-proof?

Lasse V. Karlsen 2009-02-17 13:27:29

In this example I can return different implementations of the factory, but each must create a provider which implements IDisposable. This isn't ideal but at least gives you a clue about the semantics. Perhaps this isn't the question you were asking?

Chris Ballard 2009-02-17 13:53:48

No, my question is: Should I, through the IoC container, enforce that all such interfaces and concrete types implement IDisposable, or should I leave that as an exercise for the user?

Lasse V. Karlsen 2009-02-17 13:55:15

I think we have to make the developer responsible - IDisposable is all about telling the runtime that we are done with a resource, and not leaving this to the GC. All we can do is make it clearer that we are creating an object which needs to be explicitly disposed.

Chris Ballard 2009-02-18 13:33:08

Answer 2

+2 A:

(Disclaimer: I'm answering this based on java stuff. Although I program C# I haven't proxied anything in C# but I know it's possible. Sorry about the java terminology)

You could let the IoC framework inspect the object being constructed to see if it supports IDisposable. If not, you could use a dynamic proxy to wrap the actual object that the IoC framework provides to the client code. This dynamic proxy could implement IDisposable, so that you'd always deliver a IDisposable to the client. As long as you're working with interfaces that should be fairly simple ?

Then you'd just have the problem of communicating to the developer when the object is an IDisposable. I'm not really sure how this'd be done in a nice manner.

krosenvold 2009-02-17 20:15:06

Well, this sounds like "always return an IDisposable object from the IoC container" and then the easiest solution would be to make that a criteria for the concrete types. The implementation of that interface could of course be left empty, so there's not much overhead code-wise, just one method.

Lasse V. Karlsen 2009-02-18 08:25:53

Yes I suppose there's little difference. I suppose the basic problem is that you need to communicate the disposability of the object to the client code, so I think there's little hope ;)

krosenvold 2009-02-18 08:52:56

I'd go for not supporting disposable objects.

krosenvold 2009-02-18 08:56:31

Answer 3

+1 A:

You actually came up with a very dirty solution: your IService contract violates the SRP, wich is a big no-no.

What I recommend is to distinguish so-called "singleton" services from so-called "prototype" services. Lifetime of "singleton" ones is managed by the container, which may query at runtime whether a particular instance implements IDisposable and invoke Dispose() on shutdown if so.

Managing prototypes, on the other hand, is totally the responsibility of the calling code.

Anton Gogolev 2009-04-27 11:48:21

ansaurus

tags:

views:

answers:

ServiceContainer, IoC, and disposable objects

related questions