Appropriate Situation for Using IoC Container?

Question

Let's say I have a common WCF service and console app project that do not change across client specific deployments. I have some interfaces in the common projects that are implemented by specific client code. The client code obviously changes from client to client. I'm thinking this would be an appropriate use for an IoC container. In my common service projects, I drop the client specific dll in the bin and wire up the dependencies via IoC. The only trick is that this has to be done dynamically as the common service projects can't have a direct reference on a specific client project. Not a big deal though.

Is this correct usage of an IoC container?

Answer 1

If I understood correctly your system, maybe you can benefit from taking a look at the Managed Extensibility Framework.

Answer 2

Dependency Injection (DI - what you call IoC) is a slightly different beast than supporting Add-Ins/PlugIns.

The purpose of DI is to manage dependencies and decrease coupling between different parts of a system. It can feel a bit like Add-Ins, but is slightly different because you usually just replace one implementation of an interface with another.

With Add-Ins, on the other hand, the purpose is to provide zero, one, or many implementations of the same service.

In both cases you may want to resolve the implementations at run-time based on configuration files, scanning a folder or similar, so there's a great degree of overlap.

What makes it even more complicated is that Add-Ins may have depedencies in their own right, and you may want to support that (moving into DI territory).

For the Add-In scenario, I will second Konamimam's suggestion: MEF sounds like it would fit your requirements.

Answer 3

Yes, this will work fine. You just need to make sure the client specific DLLs bring along their own registration. With StructureMap, it would be implemented as Registry classes in the client specific DLLs.