Q1: Apparently in Prism v4 you need to make an up-front binary choice of
either MEF or Unity as your "DI container"? (I guess you could choose another
DI-container too, but the in-the-box options will be MEF or Unity). True?
Yes, the choice of DI containers is a key decisison for your app. You should be able to integrate any container,, but only Unity and MEF are supported out of the box.
Q2: I assume Prism requires some kind of "DI container" under the covers in order
to work? True? I can see that being true for the modularization features, but
what about the eventing and commanding features. Could those be used with "DI"
There are parts of Prism that require a DI container (modularity for example), but both the event aggreagator and the commanding features shoudl work without a container.
Q3: Can someone summarize the high-level reasons to go with one or the other
(MEF versus Unity)? Or are they both pretty much the same? If I choose one today, what am I going to lose?
The short answer is that they are fairly close in functionality, but very different in styles.
The full answer is:
In Chapter 3: Managing Dependencies Between Components, we outline some of the differences between the containers and leave the choice to the developer based on the needs of the project. With Prism being container agnostic,
developers can write a few simple classes for any container and plug it into Prism. In the box, we have support of Unity and MEF, but the extension point is there and documented.
Here are some of the big differences between MEF and Unity:
- MEF is not a DI container (it’s a dynamic add-in framework that uses DI techniques), but can be made to act like a DI container for simple scenarios. It has the advantage of being in the .NET 4.0 framework.
- Unity is a full DI container. It supports .NET 3.5 and 4.0. It also supports more complex DI things like open generics, policy injection (AOP), etc.
The development styles differ quite a bit due to the different approaches in design an scenarios for usage. With MEF, it is recommended to do declarative programming (attributes for registration/exporting and importing).
With Unity, the more common approach is a lot more imperative (registration via code rather than attributes). Constructor injection is preferred in Unity (even though it can do property injection) vs property injection is preferred in MEF (even though
it can do constructor injection).
Q3.x: If I decide 6 months from now that I want to switch to the other how hard will be?
We (the Prism v4 team) ported most of the quickstarts that Prism v2 shipped with from Unity to MEF to prove out that we could get feature parity with the two containers, even if not all of them made it "in the box".
We also ported the Stock Trader RI from Unity to MEF (and integrated our MVVM guidance and some navigation as well). Neither of these efforts was very big, and I think the stock trader took less than a day to get the Unity to MEF conversion done. The
biggest challenge you will run into is the different styles, which I highlighted above. Once you get past the style differences, it is a matter of ensuring all the types, services, etc get registered properly in the container, which requires deciphering
a lot of very verbose error messages in exceptions.
I'd recommend skimming chapter 3 in the CHM for more info.
Let me know if you have more questions.