I find it important to note that although MEF is not an IoC container in the usual sense, it does an inverse of control. In fact, I would not agree with this and said that MEF is an IoC container, like any other. The real difference between the word Unity and MEF is that MEF by default supports composition by explicit type resolution and detects the type above the configuration. But, as we saw in the MEFContrib project, it is possible that MEF will be more like a traditional IoC container. MEF provides you with an excellent foundation for the modular behavior of components, taking a large amount of complex transplantation and the way it is developed, which allows you to add more functionality to it. Say, for example, you have an existing code base built around another IoC container or service locator, you can connect an ExportProvider to it ExportProvider that you can connect the provider to a service locator, such as the Common Service Locator , and then connect a compatible CSL implementation and create composite parts of the MEF using types derived from another IoC container. MEF also performs dependency injection.
If you want to avoid depending on a specific IoC container or MEF itself, you can always use something like the Common Service Locator, which is an abstraction of the usual container operations. Thus, if you need / need to change how everything is connected, it is relatively painless. Compatible CSL implementations exist for most IoC and MEF containers.
Hope this helps.
Matthew abbott
source share