MEF vs. Unity in composite application (Prism)

On April 27, 2011, in C#, Programming, by Akash Kava

This article describes differences between MEF and Unity which may help you in deciding which technology you must use while making composite application.

Both technologies are useful and easy to understand, and offer a rich set of features that can make integration of various software components very easy. However, both being little different in functioning they offer exact same level of features but choosing wrong one can lead to chaos.

So we will drill down to differences between their operations.



Unity creates new instance of type by default.

MEF creates singleton instance of type by default.

Unity does not require registration for classes. This means you can instantiate any other third party type.

MEF requires Export attribute to be specified on the class. MEF cannot create instance of third party type unless it defines Export.

Unity requires type registration in code for interface types.

No registration, simple Export attribute does it all.

Unity container can compose IUnityContainer property in the composed class where you can further access it easily in your own scope. This behavior is not useful for Plugin architecture as getting access to IUnityContainer may result in full access to your application.

MEF does not allow composition of CompositionContainer, which blocks access to MEF in your own scope if you do not have CompositionContainer. This is useful in Plugin architecture where third party code has limited access to your application. 

Unity offers injection method mechanism, that can define IUnityContainer parameter and get the unity container object, with which you can compose other private properties manually.

MEF can only compose public properties, this is dangerous as anyone can change public property and make application crash easily.

Inside your application’s framework code, Unity serves the best as it gives you full control over type hierarchy, lifecycle and allows you to utilize third party components easily without writing much of code. 

Inside your application, MEF will put lots of restrictions in which your framework can operate as it cannot easily compose third party components and it will force you to write numerous attributes in your code without which it will fail drastically.

Mostly, User Interface objects like your View, or UserControl or any UIElement can never be shared as no UIElement can have two parents at same time. So default behavior of Unity to create a new instance of type is very helpful.

Default behavior of MEF will create only one single instance of UI object, that will lead to trouble, not only that, if UI object is third party tool, MEF will not compose it. You can create multiple copies of exported type by specifying one more attribute called [PartCreationPolicy(Shared)], however it is very time comsuming and tedious to define this one every UI related type we create.

Unity does allow singleton objects, but for that you have to register an instance to the container.

MEF by default creates singleton object only.

Unity does not allow multiple registrations for same instance in same scope sharing same interface but different type.

MEF allows multiple singleton objects of different type sharing same interface.

Unity works best for MVVM, as composing user interface parts can be very easy with unity.

MEF does not work great with MVVM as it will create singleton objects that will behave strangely in runtime and lead to UI failure.

Unity is not good for Modularity, as composing IUnityContainer will offer more control of unity lifecycle to third party modules.

MEF is good for Modularity, as it will not allow modification of composition thus offering great deal of security between modules.

So, to develop a framework, MVVM Crud application and a UI framework, Unity is the best.

To expose some functionality of your application for third party modules to register and access limited functionality, MEF is the best.


Following is outline of how your application should be,

Unity Container must compose and manage your application’s framework, UI and MEF modules.

MEF will only expose limited functionality from Unity Container to third party modules.

No module, through MEF should have access to unity container at all.

Thank you for reading this article, please put your suggestions below in the comment. I do not intend to make any specific rules and regulations here but I am suggesting the architecture based on the differences I have outlined.

Tagged with:  

6 Responses to MEF vs. Unity in composite application (Prism)

  1. Your article is inaccurate. Apparently you have a lot more experience and bias to Unity, and your conclusion is incorrect. It’s not that the conclusion should be different – both Unity and MEF have your place – but making it look like an objective decision is misleading because it is truly a subjective choice based on familiarity with the tools.

    MEF does not require the export attribute. You can apply an inherited export to an interface for implicit exports, and you can also write a custom export provider that is not attribute-based.

    MEF does not have to compose public properties. You can use an importing constructor and keep the composed properties private.

    Your idea that MEF forces you to use attributes is simply wrong. There are plenty of examples of fluent and even convention-based MEF that requires minimal to no configuration. MEF also gives you full contorl over lifetime management.

    MEF’s default is singleton but this is easily overridden, the same way you mention that Unity is easily overridden to provide singleton.

    I don’t know where you can qualify that MEF works terribly for MVVM. We write tons of enterprise line of business applications using MVVM and MEF. I have a framework based on MEF because it is so helpful for MVVM. If you are getting “strange runtime/UI failures” it is from your lack of knowledge/experience, not a limitation of MEF.

  2. John says:

    Hi, nice article. I have been researching this quite a bit recently and there is much debate as to how say MEF + Unity can co-exist.

    The main reason i use both in MVC3 is becuase MEF is great at the plug-in pattern for a whole assembly at ‘run-time’, while something like Unity or Ninject make the code easier to change at ‘design-time.’

    cheers, John

  3. Akash Kava says:

    Well I am not biased towards Unity, I am saying what Unity is good for and what MEF is good for. I understand customization of MEF and Unity both, both can be customized to take each other’s place, but can we count man hours involved in it and what benefit do we get. Also I am not drawing any line here, I have clearly mentioned that this is what I feel, how both the technologies should be used out of the box without involving too much of customization that is difficult to maintain over multiple projects and over lifecycles of project, employee and technology itself. Being at the level I am, I can understand underlying architecture of Unity and MEF and I know how to control them, but various programmers, people from various technologies are involved in project life cycle, I do not want to teach everyone how to customize MEF or Unity to take each other’s place, rather I want them to use the best of both worlds and give me a faster turnaround.

  4. Gharieb says:

    Hi All, I’m with Akash Kava in this post and i think this comparison is valid by default behavior fot both MEF and Unity

  5. Yasmany says:

    Hi, I’m new using MEF and I have a question. I have an interface “IVehicle” and two classes implementing this interface, then I have some other class with an IVehicle attribute. If I export my classes as IVehicle, then, when I inject the constructor and pass it the IVehicle object as parameter, I got an error, I suppose that is beacause I’m exporting two classes under the same contract (I add the attribute [Export(typeof(IVehicle))] to both classes that implement such interface) and then the framework can’t resolve wich contract use. I mark the constructor of the class that uses the IVehicle object with the [ImportingConstructor] attribute
    How can I solve this??

    P.D What I exactly want is to have various classes implementing an interface, and then, from another class, have an object of this interface which could take any of the types that implement such interface.

  6. Akash Kava says:

    Well I will look for better solution but what you can do is, create an additional interface called IExportedVehical derived from IVehical and use it only on one class you need to export.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>