MEF VS IoC - SoftwareDesign/MEFResearch GitHub Wiki

In a nutshell, it’s correct to say that the functionality of the MEF and of a typical IoC framework overlap, but don’t coincide. With most IoC frameworks you can perform tasks that the MEF just doesn’t support. You could probably employ a functionally rich IoC container and, with some effort on your own, emulate some MEF-specific capabilities. In light of this, the question that I’m frequently asked when I mention the MEF in classes and everyday work is: What’s the difference between the MEF and an IoC tool? And when do I really need the MEF?

My thought is that, at its core, the MEF is an IoC framework built right into the .NET Framework. It’s not as powerful as many of the popular IoC frameworks today, but it can perform the basic tasks of a typical IoC container quite well.

Today, IoC frameworks have three typical capabilities. First, they can act as the factory of a graph of objects and walk through the chain of object relationships and dependencies to create an instance of any required and registered type. Second, an IoC framework can manage the lifetime of created instances and offer caching and pooling capabilities. Third, most IoC frameworks support interception and offer to create dynamic proxies around instances of specific types so that developers can pre- and post-process the execution of methods. I covered interception in Unity 2.0 in January (msdn.microsoft.com/magazine/gg535676).

The MEF, in a way, can serve as the factory of a graph of objects, meaning that it can recognize and handle members on a class that need be resolved at run time. The MEF also provides minimal support for caching instances, meaning that some caching capabilities exist, but they’re not as functionally rich as in some other IoC frameworks. Finally, in the version shipped with the .NET Framework 4, the MEF lacks interception capabilities entirely.

Having said that, when should you use the MEF? If you’ve never used an IoC framework and just need to clean up the design of your system by adding a bit of dependency injection, then the MEF can be an easy start. As long as you can quickly achieve your goals with it, the MEF is preferable to an IoC framework.

On the other hand, if you’ve spent years working with one or more IoC frameworks and can squeeze any bit of functionality out of them, then there’s probably nothing that the MEF can give you except, perhaps, its ability to scan various types of catalogs to find matching types. It should be noted, however, that some IoC frameworks such as StructureMap (structuremap.net/structuremap/ScanningAssemblies.htm) already offer to scan directories and assemblies to look for specific types or implementations of given interfaces. With the MEF, this is probably easier and more direct to do than with StructureMap (and a few others).

In summary, the first question to answer is whether you’re looking for general extensibility. If the answer is yes, then the MEF must be considered—perhaps in addition to an IoC tool if you also need to handle dependencies, singletons and interception. If the answer is no, then the best approach is using an IoC framework unless you have basic needs that the MEF can address as well. All things being equal, the MEF is preferable to an IoC framework because it’s built right into the .NET Framework and you don’t need to take any additional dependencies.

Note: The content on this page is extract from Dino Esposito's article "Application Extensibility: MEF vs. IoC"