Difference between MEF and IoC containers (like Unity, Autofac, SMap, Ninject, Windsor.Spring.net, etc.)

Eventually what I have concluded about the MEF vs IoC container is as follows:

MEF is preferred to be used when one has to deal with unknown types or a plugin based architecture.

IoC containers are preferred to be used with known types.

Moreover, MEF is an architectural solution for dependency injection

Whereas, IoC containers are code-level solutions for dependency injection.

IoC containers are just dependency injection techniques which populates the instance of a class and if the constructor of those classes requires objects of other classes, then IoC also injects the required objects. But MEF does more than just dependency injection. Although, MEF also uses an IoC-based approach for dependency injection, but MEF does so many other things apart from dependency injection.

MEF has got two components:

  1. Catalog: Is responsible for discovering extension

  2. Container: Provides the ability to load an extension to a running application

MEF is more than just dependency injection techniques. It is used wherein we need a plugin-based architecture for our application, but at the same time MEF uses an IoC-based approach for dependency injection.

I am expecting more people to comment on this.


IoC is an architectural design strategy, and MEF is an implementation of the design pattern dependency injection. Dependency injection (DI) is often the implementation strategy of IoC. Often the term IoC container is used, suggesting that IoC is the technique.

No, it is otherwise. IoC is a broad concept and DI is the design pattern to implement the core of IoC. MEF is some form of DI, but it has not all fundamental features of IoC.

MEF uses composition to find out the dependencies it needs to resolve. That is much like a lot of other IoC containers, for instance Pico and Spring. But it stops there. I did not see any life cycle management nor pooling configuration. The latter two do I consider to be a fundamental part of IoC (not of DI), because the performance of the caller should not suffer because of the memory consumption used by the callee.

The IoC principle is a service to the caller and the callee by loosely coupling them. That way both functionalities can work optimized. MEF might have the problem that there are issues with optimization. For instance, when you have a call from the menu to a database, then at some time a call to the database will be made. It is always best to use pooling for that. MEF is not capable of doing that.

The type of application should be independent of the choice for a design pattern. There is not a big difference between a desktop or a web application. Both are user interfaces, and both should be able to use MEF and IoC. If the functionality is straightforward and does not need to cross optimization boundaries (like database calls), then MEF is the first choice, because it is a framework that is present when using .NET 4. Then it could be useful, but if a call crosses an optimization boundary (like the parsing or uploading of a file), then the use of an IoC container is more fruitful for performance and maintenance.

Information I used:

  • Hanselminutes 148 (podcast interview with Glenn Block).

  • Managed Extensibility Framework (MEF) (MSDN)

  • Cutting Edge - Application Extensibility: MEF vs. IoC

  • Inversion of Control Containers and the Dependency Injection pattern

  • Inversion of control (Wikipedia)

  • Why exactly isn't MEF a DI/IoC container?