This project has moved and is read-only. For the latest updates, please go here.

Why MEF compared against Unity?

Jan 5, 2009 at 5:18 AM
Edited Jan 5, 2009 at 5:40 AM
I would say that I am relatively new to the application of the IoC and Dependency Injection patterns and am having a difficult time trying to determine why would someone use MEF rather than Unity? They are both DI containers and can both import types from external assemblies, and Unity by the way also supports composition via configuration files. Forgive my stupidity, but what makes MEF so special? Does it have anything to do with MEF's caching capabilities or perhaps its ability to find exported parts in assemblies in an arbitrary path?

So far the only difference that I can tell is the project description. The description is geared more towards being a "extensibility" framework, probably so that it can break convention and not have to stick to the role of a DI container exclusively if an issue arises that warrants it. Forgive me if I am wrong.
Jan 5, 2009 at 8:13 AM
Edited Jan 5, 2009 at 8:14 AM

Hi Jeffrey

MEF and other IoC containers certainly do overlap. What's special about MEF is that it targets a very specific set of problems, namely building applications, frameworks and extensions that have open-ended extensibility

Picture this, you purchase a CRM system which other vendors can extend. The number of extensions (we call them parts) are unlimited, the app has no hard knowledge of the number or type. Now you go and purchase a 3rd party module for that system. To "install" it, the files are simply copied to the bin folder.When the app runs, everything is automatically discovered based on known contracts (does not have to be type) and wired up. There's no central config, the code is the configuration. This allows different vendors to play in the same space without clobbering each other, and without having knowledge of one another, etc.  Now imagine that the 3rd party extension itself is also extensible. In the same way you can purchase other vendor solutions to extend it. The model is the same, assemblies are copied to the bin folder, and at runtime the new extension appears. The discovery extends further in allowing applications to query what is out there and make determinations based on what is available. For example it can see there are 2 extensions, and determine to only load one over the other. MEF allows parts to provide additonal metadata that can be used as a discrminator for loading. That metadata and all the available information about extensions can be cached as you mentioned. Combined with the delay loading, this means extensible apps have faster load times and smaller memory footprints.

Contrast that to the way IoC containers such as Unity tend to be used. In general they are used for managing a known set of components for which you specifically register different implementations (types) from environment to environment. For example if you are doing TDD, you will have a stub logger that gets injected in unit tests, while Unity provides the real version at runtime.  You  may also have different configurations of your product which the container can inject. For example your  app can support MySQL or SQL Server repositories. Depending on a customer needs you deploy the correct implementation of IRespository along with configuration for registering it.You make the determination of what is known. You specifically decide what gets used in each environment.

Now you can build on top of an IoC other mechanisms to do to things like discovery and you can create your own protocols. The difference about MEF is it is fundamentally designed to to specifically support it and includes that protocol.

In summary I would say that MEF composes a set of unknown things that are discovered and identified through a known contract. IoC containers are focused on a set of known things which are speifically registered by type. (or with a convention).

These are several other differences, but this is a fundmental difference in how we designed MEF.

Let me now if this clarifies things for you.


Jan 5, 2009 at 4:49 PM
Thanks Glenn!

Very much so. Thanks for your speedy response.
Jan 5, 2009 at 7:36 PM
Glenn, great response.  I find these hypothetical scenarios to be very helpful in getting a clearer picture of how MEF can be used.  MEF is such a powerful technology that thinking in terms of more concrete scenarios is very helpful in getting the imagination going as to what can be done with MEF.  Thanks!
Jan 5, 2009 at 9:40 PM
@gblock: Mhhmmmm... Not convinced!
While the example is good and to the point in  promoting MEF and a very neat one in explaining the differences between Unity and MEF , the scenario  is highly impractical.

1) If I am a software vendor and I sell a software based on MEF then I will be extremely careful that there are no other vendors piggybacking/extending my application. I will also make sure that the other vendor is licensed by me to write such additions. IF at all that should happen I will provide APIs and NOT ALLOW EXTENSIONS

2)There is also the other issue of changing the configuration in an existing applications. What Do I mean by this? Applications that discover and use the discovered should be made configurable to say what all can be discovered and what in the discovered pool can be made use of.. I had "farted" (since no other words come close to the way I do my discussions) about this in some previous threads. If it is a homegrown application then there is a possibility. For of-the-shelf types, this is a nightmare.
Jan 5, 2009 at 10:50 PM
Hi Ganesh

1. That would depend on the app. Take Office for example, it provides a highly extensible model that basically anyone can extend. Addins can be signed for ensuring that they have a valid certificate etc. However, extending the app itself is as easy as getting your hands on an SDK which it is very simple to get a hold of. Moving to a model like MEF would basically mean removing the imperative coding part.

2. I think I addressed this in the other post. There are several different ways to approach this level of configuration in MEF.

Jan 6, 2009 at 3:13 PM
Hi gblock,
that, the office being an example of extensibility is something I had said in another thread about parts licensing model. Like I had said, it is easy to do MEF on a single user / "small office" applications where the application need not be constantly configured to be used efficiently and the application resides in a user's desktop. But in a larger enterprise wide application, not that you do not know, there would be several features that gets loaded but seldom used. If it does load by user profile then there is the issue of repetitive instantiation of objects and a configuration nightmare. Each time a new user is added or deleted we have to , other than existing default profile based navigational issues , now handle "object instantiation configuration" as well. This also gets complicated when newer assemblies/parts/dlls are introduced. For all practical purposes the system has to be shut down for the newer dlls to be added like it is being done is legacy .net enterprise applications. One has to be fully aware of the other components that come with 3rd-party MEF extensions. For example, say, data access components, which might duplicate an existing DAC or completely create a new logic for persisting data.
Jan 7, 2009 at 9:46 AM

When you say object instantiation configuration, what do you mean exactly? Can you be more specific, and give me a specific concrete scenario that illustrates the problem?

Dec 5, 2010 at 12:52 PM
Edited Apr 20, 2011 at 1:04 PM