MEF or Unity for Prism v4 "Dependency Injection"?

I realize this is similar (but not exactly the same) as
this existing post, which
resulted in a documentation work item. For one thing, this post has a more
explicit title.

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?

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 without
"DI" underneath?

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? If I decide 6 months from now that I want to switch to
the other how hard will be? I definitely want to sound cool and up-to-date
when I talk with my peers, which is pushing me toward MEF ;).

One observation:
Offering two ways of doing things that are almost the same can be frustrating
when you're looking for "guidance".

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 orderto 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"
underneath?

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.

Thanks for your quick and detailed response. After I read Chapters 3 and 4 of the Prism v4 CHM
I may have some follow up questions about the technical details.

Below is a bit more grumbling regarding the problems of including both MEF and Unity as DI options in the "guidance":

Part of the reason "average" programmers like me come to a framework like Prism is because we don't have time to learn all the details necessary to make an informed choice on every technical detail. We just want to be told and shown
what the current best practice is, and then be able to go use it.

Long term it seems undesirable to include two options that are so similar. This reminds me of the choice between Linq-2-SQL and Entity-Framework. Eventually MS had to make it clear that EF was "the chosen one", even though folks
who were using L2S were unhappy.

One irritation of supporting both Unity and MEF is that now you need to support both in your samples and documentation. As I was reading Ch3 and Ch4 in the CHM I was constantly having to think: "Is this referring to the Unity-way or
the MEF-way? Did they update this part of the documentation yet to cover the MEF-way?".

The Prism source-tree is complex enough as it is with having to support both WPF and Silverlight, but that is more justifiable, because there are _lots_ of things you only can do in either WPF or SL.

I understand your frustration. As far as the docs go, I will have someone make another pass through to make the Unity/MEF difference more obvious where possible and see if we can split things out a bit more.

Prism was architected with a container agnostic design, and we wanted to keep that principle going forward. Originally, Unity was just a means to an end in showing a DI container plugged into Prism. For v4, there were enough
requests for MEF support that we decided to add it and show not just the one option for DI in the guidance, but two.

Again, thanks for your feedback. I'll be passing it on to the rest of the team.

Another opinion:
I asked
Jeremy Likeness on his blog for his opinion on the "Prism with MEF or Unity?" question. Somewhat surprisingly, although Jeremy is a big fan of MEF, he actually recommended going with Unity when using Prism:

Partial quote from Jeremy:While it is interesting to see PRISM work with MEF, that implementation hasn't sold me yet. Why? Because there is a lot of overhead and set up to get, for example, a module to load even with MEF, when MEF by itself simply provides a nice DeploymentCatalog.

This reminds me of choosing a camera to buy. It's easy for me to get so freaked out by all the choices that I put off buying
anything. It's better to just buy something and get started. Once you have camera #1 you can learn about it. Later you can buy special-purpose camera #2 or lens #1B, but you've got to start somewhere.

This was a a great thread to read. It answered some questions of mine. What would be neat is to have a guide based on application type.

A website could have a list of categories of types of applications people build, then sub categories to be more specific with options for even greater specificity, run the search and the results show programmers recommended approached with some details on
why they chose that approach rather than another. The site can have input forms for developers to enter their projetc decision information so that a consistent layout of information exists for all posts. The site could have some standards
like rating and review notes on portability, scalability etc.

A site like this would be very useful to so many people. The contributors ratings, skill set ,ect. should be viewable. This would help programmers find information they seek sooner and not get lost in the blogasphere, etc.

I noticed that the "MVVM RI" sample (#3 above) doesn't use UnityBootstrapper, MefBootstrapper, or apparently anything from the Prism.Modularity namespace (ModuleCatalog, ModuleManager, etc.). Instead it gets some of the equivalent goodness
by using MEF directly. (Apparently Jeremy Likeness favored this Direct-MEF approach.)

This makes me wonder if the additional complexity of Prism.Modularity and MefBootstrapper are worth it in my own app.

If I'm willing to take a direct dependency on MEF (which Prism4.chm says Prism deliberately did NOT want to do, in order to be container-independent) how much work would it take to equal all the goodness of Prism.Modularity? Or perhaps I'd end
up with wrapper classes on top of MEF that were more or less the same thing as Prism.Modularity ;) ?

In the Prism documentation there is a document that you can find interesting, which is
for evaluating the Composite Application Guidance. So far this has not been updated for Prism 4 on MSDN, but most of the concepts are still the same or similar. If you downloaded
Prism v4, you could take a look at the Evaluating Prism section in the
Chapter 1: Introduction (updated) of the Prism4.chm.

Additionally, the product team is working on the "Stock Trader RI". So in my opinion, this will help to see how Prism-MEF work in a more complex scenario.