MEF & separate Interface assembly leads to "Interface for every class"

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 need access to the whole environment. The application has a list with concrete implementations for e开发者_C百科ach type, composed by MEF.

The environment consists of:

• several repositories
• current application request
• render engine
• navigation engine
• plus some static utility classes

How can I put the Interface definitions in a seperate assembly and at the same time specify the environment injection?

Obviously, I can't just reference the main assembly because that needs to reference the contract assembly and I can't create a circular reference.

It seems that I need to create an interface for each of the environment classes, and their publicly available types and so on... There has to be a better way?!

Maybe I'm also missing the obvious bigger flaw here, if anyone could point it out for me?

---

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.