MEF versus any IoC

Question

Looking at the Microsoft Managed Extensibility Framework (MEF) and various IoC containers (like Unity), I don’t see when to use one type of solution for another. More specifically, it seems that MEF handles most patterns like IoC and that an IoC container such as Unity will not be so necessary.

Ideally, I would like to see a good use case when IoC container will be used instead of IOC or in addition to MEF.

Answer 1

When welding, the main difference is that IoC containers are usually most useful for static dependencies (known at compile time), and MEF is usually most useful with dynamic dependencies (known only at runtime).

As such, they are both compositional engines, but the emphasis is very different for each template. Thus, design decisions vary greatly, as the MEF is optimized around detecting unknown parts rather than registering known parts.

Think of it this way: if you are developing your entire application, it is best to use an IoC container. If you are writing about an extension so that third-party developers will expand your system, MEF is probably the best.

In addition, the article in @Pavel Nikolov's answer gives some great direction (it was written by Glenn Block, the MEF program manager).

Answer 2

I have been using MEF for some time, and the key factor when we use it instead of IOC products is that we regularly have 3-5 implementations of this interface, which are in our plugins directory at a given time. Which of these implementations should be used is something that can only be solved at runtime.

MEF can let you do just that. As a rule, the IOC is oriented so that you can swap, for a conical example, an IUserRepository based on the ORM 1 product for the ORM 2 product at some point in the future. However, most IOC decisions suggest that only one IUserRepository will be in effect at a given time.

If, however, you need to select one based on the input for a given page request, IOC containers are usually lost.

As an example, we check our rights and our check through MEF plugins for a large web application that I have been working on for some time. Using MEF, we can see when the CreateOn date is recorded and go to the validation plugin that actually acted when the record was created, and start the BOTH record through this plugin AND validator, which is currently valid, and compare the record's validity over time.

This type of power also allows us to define pattern overflows for plugins. The applications I'm working on are actually the same code base that was deployed for 30+ implementations. So, we usually look for plugins asking for:

• An interface implementation that is specific to the current site and specific record type.
• An interface implementation specific to the current site, but working with any type of record.
• An interface that works for any site and any entry.

This allows us to combine the set of default plugins that will be involved, but only if this particular implementation does not cancel it with specific client rules.

IOC is a great technology, but it seems to make it easier to code interfaces instead of specific implementations. However, replacing these implementations is more likely a type of project event in the IOC. In MEF, you take on the flexibility of interfaces and specific implementations, and you do this with the runtime of many of the available parameters.

Answer 3

I apologize for being off topic. I just wanted to say that there are two drawbacks that make MEF an unnecessary complication:

• this is an attribute that does not help you understand why everything works the way they are. There is no way to get to the details worn in the insides of the frame to see what exactly is happening there. There is no way to get a trace log or connect to enable mechanisms and manually handle unresolved situations.

• it does not have a troubleshooting mechanism to find out the reasons for the failure of some parts. Despite the fact that it indicates a faulty part, it does not tell you why this part failed.

Therefore, I am very disappointed with this. I spent too much time battling with windmills trying to run several classes instead of working on real problems. I am convinced that there is nothing better than the old-school injection method, when you have full control over what is created, when it can track anything in the VS debugger. I would like someone who defended MEF to present a ton of good reasons why I should choose it for a simple DI.

Answer 4

I agree that MEF may be a fully compatible IoC card. In fact, I'm writing an application right now based on using MEF for both extensibility and IoC. I took the common parts and turned it into a “framework” and opened it as my own structure called SoapBox Core in case people want to see how it works.

In particular, see how Host works if you want to see MEF in action.