Prism's MEF Unity container Difference

http://akashkava.com/blog/391/mef-vs-unity-in-composite-application-prism/

This article describes differences between MEF and Unity which could help you in deciding which technology your must use Whil e Making composite application.

Both Technologies is useful and easy to understand, and offer a rich set of features the 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 Lea D to chaos.

So we'll 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 and third party type.	MEF requires Export attribute to being 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 can further access it easily in your Own scope. This behavior was not useful for Plugin architecture as getting access to Iunitycontainer could result in full access to your Application.	MEF does not allow composition of compositioncontainer, which blocks access to MEF in your own scopes if you does not have Co Mpositioncontainer. This was useful in Plugin architecture where the third party code had limited access to your application.
Unity offers injection method mechanism, that can define Iunitycontainer parameter and get the Unity container object, wit h which you can compose other private properties manually.	MEF can only compose public properties, the 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 your full control Over type hierarchy, lifecycle and allows-utilize third party components easily without writing much of code.	Inside your application, MEF would put lots of restrictions in which your framework can O Perate as it cannot easily compose third party components and it'll force do you-write numerous attributes in your code Without which it would fail drastically.
Mostly, User Interface objects like your View, or UserControl or any UIElement can never be shared as no UIElement can hav E-Parents at same time. So default behavior of Unity to create a new instance of type is very helpful.	Default behavior of MEF would create only one single instance of UI object, that would leads to trouble, and not only that, if UI Object is the third party tool, MEF would not compose it. You can create multiple copies of exported type by specifying one more attribute called [Partcreationpolicy (Shared)], Howe Ver 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's has to register a instance to the container.	MEF By default creates singleton object only.
Unity does not allow multiple registrations to 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 is very easy with unity.	MEF does not work great with MVVM as it would create singleton objects that would behave strangely in runtime and leads to UI Failure.
Unity isn't good for modularity, as composing Iunitycontainer would offer more control of Unity lifecycle to third party m Odules.	MEF is good for modularity, as it won't 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 was 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 what your application should be,

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

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

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

Thank you to reading this article and put your suggestions below in the comment. I don't intend to make any specific rules and regulations here but I am suggesting the architecture based on the Differen Ces I have outlined.

(GO) Prism's MEF Unity container difference