Prism with MEF : not CAB again ?!

Topics: Prism v2 - WPF 4, Prism v4 - Silverlight 4, Prism v4 - WPF 4
Oct 7, 2010 at 1:05 PM

Hi guys,

Since this is my first post, thanks to all contributors for the great work and for better software (Let's hope I'll get there !!).


About a year ago, I discovered "patterns & practices" and found quantity of rich documentation like : "Microsoft Application Architecture Guide", "Enterprise Library", Unity Container, ...

But going into code examples, using software factory and CAB, I stepped back, lost by the complexity AND the difficulty to understand routines.

I know attributes are part of the framework, and I use them when necessary, but I personnaly found the extensive use of them makes code harder to read, applications harder to understand and harder to explain to other programmers (beginners or not).


About half a year ago, around the time CAL got renamed to Prism, everything started to clear again : compact library, great separation of concerns, nice examples, ...

I was starting to get familiar with boostrapper, modularity, container, communication, UI composition and even new concepts like M-V-VM, or shared code between Silverlight and WPF.

Since the introduction of MEF within Prism, everything got MEF-coded, and the StrockTraderRI example in the last version (Prism4Drop9) is getting unreadable to me.

I don't say MEF is bad, I don't say I'll never use it (I will probably take a look into it) but I wish Prism versions and examples could remain POCU :-) "plain old code understandable".


Anyway, is it just the way you'd rather code or what's the difference (performance, memory, accessibility, ...) between : container.RegisterType<ILoggerFacade, LoggerFacade> and [Export(typeof(ILoggerFacade)] public class LoggerFacade : ILoggerFacade ...

(I'm not talking here about differences between both containers, which are well explained in documentation).


Well, I hope to stick with Prism for a long time now, so that's the thought I wanted to share.



PS : I have no problem with using previous versions of Prism, but as new functionnality (and bug corrections) are added within each new versions, I like to stay up to date.

Oct 7, 2010 at 6:22 PM
Edited Oct 7, 2010 at 6:29 PM

Hi Stéphane,

Nice to see that you started using the drop 9 and thanks for your feedback, since this is really valuable. As you mentioned the attributes are part of the .NET, and MEFEE code is decoration-oriented (declarative), while Unity tends to be more imperative. But Prism is container-agnostic and choosing the container is one the key decisions when starting with Prism.

Therefore, I think that you can take this into account when choosing /changing your container, since this is something valid.

For more information on this topic, you could take a look at the following forum thread, where a member of the product team has answered interesting questions about this:

Fernando Antivero

Oct 8, 2010 at 7:06 AM

Thanks for the quick answer.


For the time being, I have made a choice of using Unity and the more imperative code-declaration style (vs. MEF and declarative attribute-declaration).

Anyway, as said in the post you refer to : "it is possible to port an application from Unity to MEF with just a few day(s) of work".


Do you plan to support both MEF and Unity branch through all new Prism releases ?

Do you think we'll get to see all new features (navigation, MVVM integration, ...) with nice examples/quickstarts both in MEF-style and Unity-style ?



Oct 8, 2010 at 1:42 PM

Hi Stéphane,

Regarding to your first questions, I have no official information about this. In general, this kind of decisions are taken based on design decisions from the product team as well as community feedback (e.g. community surveys).

From the Major Changes section in the Download Page: The Prism Library 4.0 code base, reference implementations, and QuickStarts are now code complete. In general, when the code is completed, the next drops contain bug fixes but do not add new features.

Fernando Antivero