MEF & separate Interface assembly leads to “Interface for every class”

Question

I\'m getting my feet wet with DI/IoC and MEF in particular.

I have a web application that has two types of parts (maybe more someday) defined by interfaces which nee

Answer 1

If you want to decouple your abstractions from their implementations (always a worthy goal), you should define those abstractions in their own assembly.

From the implementation side, this is easy to deal with, becuase you need to reference the abstractions to implement them. There's no way around that whether you use MEF or not, so that's as it has always been:

[Import(typeof(IFoo))]
public class MyFoo : IFoo { }

However, as you say, this means that you can't reference your Composition Root from the abstraction library. However, that is as it should be, because the abstractions shouldn't worry about how they get composed.

In other words, you must implement the composition of the dependencies outside of the abstraction library. A good candidate for that is the executable itself, whereas you would keep all your concrete implementations in one or separate libraries.

The abstraction library will have no references, while both consumers and implementers would need to reference it, so a dependency graph might look like this:

Composition Root --> Abstractions <-- Implementations

Where the arrows denote a reference.