http://akashkava.com/blog/391/mef-vs-unity-in-composite-application-prism/
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 |
MEF |
|
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.