Separation of interfaces and implementation

Question

From assembly(or module) perspective, what do you think of separation of Interface (1.assembly) and its Implementation (2.assembly)?

In this way we can use some IoC container to develop more decoupling desing.. Say we have an assembly 'A', which contains interfaces only. Then we have an assembly 'B' which references 'A' and implements those interfaces..It is dependent only on 'A'.

In assembly 'C' then we can use the IoC container to create objects of 'A' using dependency injection of objects from 'B'. This way 'B' and 'C' are completely unaware (not dependent) of themselves..

Answer 1

I see what you're getting at but the only reason to separate interfaces into a separate dll is if another project is going to make use of them.

If not, and the same project will use the same interfaces (but multiple times) there is no need to separate them. The IOC container can simply make use of the interfaces within the same assembly.

Consider:

Assembly 1:
    IFoo

Assembly 2:
    IOC Container
    ConcreteFooOne : IFoo

Assembly 3:
    IOC Container
    ConcreteFooTwo : IFoo

_{Note, in this case the IOC container in each of the assemblies would be in charge of taking every IFoo instance and assigning it the correct ConcreteFoo.}

This makes sense to have a separate assembly for the interfaces. Each of the other dependent assemblies (1 and 2) can use the IFoo interface. On the other hand if ConcreteFooOne and ConcreteFooTwo where both in the same assembly there would be no need to split out the IFoo interface. An IOC container could still leverage "plug and play", by switching concrete instances when required.

Update

Based on your comment you seem to be worried about tieing the IOC container to na assembly. This is not an issue, and separating the container out to a separate assembly is not a requirement. If anything, I'd class this as a code smell, let alone a pointless action.