MEF or Unity for Prism v4 "Dependency Injection"?

Topics: Prism v4 - Silverlight 4, Prism v4 - WPF 4
Sep 28, 2010 at 9:15 PM
Edited Sep 28, 2010 at 10:49 PM

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".

Thanks 

Sep 28, 2010 at 10:47 PM

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"
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.

I'd recommend skimming chapter 3 in the CHM for more info.

Let me know if you have more questions.

Sep 29, 2010 at 7:20 PM
Edited Oct 4, 2010 at 7:28 AM

Hi Michael,

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.

Thanks,
SLEverywhere

Sep 29, 2010 at 7:59 PM

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.

 

 

 

 

Sep 29, 2010 at 8:51 PM

I just ported from v2 Unity to v4 Drop 8 MEF.  Yes, a PIA, however, seems like it requires less coding.  That's always a plus. YMMV.

Sep 29, 2010 at 10:19 PM
Edited Sep 29, 2010 at 10:20 PM

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.

You can see Jeremy's full post in his blog comments here.

SLEverywhere

Sep 30, 2010 at 3:43 PM

But yet Jeremy wrote a 3 part article on using MEF with Prism. Go figure.

Sep 30, 2010 at 4:47 PM
Edited Sep 30, 2010 at 4:48 PM

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.

SLEverywhere

Sep 30, 2010 at 5:28 PM

Here, because you can decide. Use MEF.

Oct 1, 2010 at 6:11 PM

Thanks for the suggestion.  In my case I actually don't need to make a choice just yet, and since I'll be asked to justify any choice, I'm going to learn a bit more about both.

SLEverywhere

Oct 4, 2010 at 5:24 AM

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.

If anyone know of such a such, please share the links.

Oct 4, 2010 at 7:23 AM
Edited Oct 4, 2010 at 5:16 PM

Another question on Prism/Unity/MEF:

Apparently the choice is more complex!  It's not just 1) Unity or 2) MEF.  It is really:
  1) Prismized-Unity (pre-v4 "StockTrader RI" sample and "v4 ModularityWithUnity Quickstart")
  2) Prismized-MEF (v4 "StockTrader RI" sample and "v4 ModularityWithMef Quickstart")
  3) Direct-MEF  (v4-only "MVVM RI" sample).

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 ;) ?

SLEverywhere

Oct 4, 2010 at 2:07 PM

You need to read past that till it gets to the part about MefExtensions.

Oct 4, 2010 at 2:51 PM

Hi,

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.

Based on the this forum thread this update is being released on the next drop (9).

Fernando Antivero
http://blogs.southworks.net/fantivero