One of the most highly anticipated of the new technologies coming in .NET 4.0 and Silverlight 4.0 is the Managed Extensibility Framework (MEF). Folks that are familiar with Prism and that have been looking at MEF have been wondering how Prism and MEF relate to each other. At a high level, MEF shares some of the same goals as Prism in terms of supporting easy to extend applications, and this has led to a lot of questions on how MEF and Prism relate to each other and about the future direction of Prism once MEF is released next year. Hopefully this post will go a long to clearing up the confusion and give you a sense of how we think Prism and MEF will work together.
First of all, it’s important to note that Prism and MEF are very much complementary technologies. MEF allows you to create extensible applications by providing support for automatic component discovery and composition. It does not focus on application- or UI-level patterns or on any specific UI technology. Prism on the other hand provides support for creating modular composite client applications built on Silverlight and/or WPF. As such it supports a wide range of patterns including the higher level UI patterns and concepts that are need to support composite clients – such as modularity, module deployment, loosely coupled communication, commanding, and separated presentation patterns such as Model-View-ViewModel, etc.
There is clearly some overlap between MEF and Prism (since modular composite client applications are by definition extensible!!) but MEF by itself in no way replaces or obviates the need for Prism – they are each targeted at different parts of the overall puzzle. MEF in fact is fantastic news for Prism, because it means that we can now leverage core capabilities that are provided by the .NET Framework, whereas in the past we’ve had to build those capabilities as part of Prism itself.
In the next version of Prism (Prism 4.0) we’ll be focusing on leveraging MEF as much as possible and ensuring that Prism and MEF work seamlessly together. We’ll be kicking off the Prism 4.0 project early next year and, as always, we’ll be providing drops every two weeks during development so you’ll be able to provide feedback and direct the scope and focus of the project as we go. But since MEF integration is likely be one of the first things that we’ll tackle, I think it’s worth describing our current thinking on how we think Prism can leverage MEF and how they can complement each other so that you can provide feedback to us before we start. In the rest of this post I’ll outline a couple of the areas where I think MEF and Prism can be closely integrated. Let me know what you think.
Firstly, let’s talk about component composition. Prism uses the Dependency Injection pattern (DI) quite extensively because it helps to maintain loose coupling between the various components in an application. I’m not going to get into the “is MEF a DI container or isn’t it” discussion here :-) but suffice it to say that there are similarities and differences between the way MEF works and the way that typical Dependency Injection containers work. The upshot is that there are things that MEF does well and there are things that DI containers do well, but the important thing is that both MEF and DI containers promote loose coupling between components, which is a very good thing.
In the Prism 2.0 Quick Starts and the Reference Implementation we use the Unity Application Block as our DI container of choice. However, it’s important to note that the Prism code libraries themselves do NOT depend explicitly on Unity, or in fact on any specific DI container implementation. This is an important point. It was an explicit design decision to allow the use of any other DI container (such as CastleWindsor, StructureMap, AutoFac, Ninject, etc) or the use of any other kind of component composition strategy that suites your needs – such as the component composition strategy supported by MEF!
So the design of Prism allows you to use MEF with Prism 2.0 today, even though Prism 2.0 was shipped early this year way before MEF was broadly available. It’s pretty easy to use MEF instead of a DI container within a Prism module to help you wire up Views, ViewModels, Controllers, or Presenters, or to get references to EventAggregator or RegionManager instances provided by the Shell. In fact, using MEF like this can actually simplify the code somewhat since it can automatically discover available types without you having to register them explicitly with the DI container. You can also use MEF’s meta-data support to do conditional component composition. We’ll be exploring and providing guidance for these scenarios in Prism 4.0.
Another interesting possibility is to use both MEF and a DI container together in the same application. There are some advantages to this since it allows you to leverage the strengths of each in various situations. In fact, Unity 2.0 (which is currently in development as part of EntLib 5.0) will support the hybrid use of MEF and a DI container and make it seamless and straightforward. In Prism 4.0, we’ll be exploring and providing guidance for the use of MEF + DI container hybrid approaches in the context of composite client application development.
The use of MEF and/or DI container to help with component composition is pretty straightforward, and largely independent of the higher level constructs and patterns in Prism. But one area where the overlap between MEF and these higher level Prism concepts is not quite as clear cut is in the area of Catalogs and Modules. This area has caused some confusion in part because of overlapping terminology and, in some cases, because of the similar concepts applied at different levels of granularity.
To recap, Prism uses the notion of a module to represent a collection of features, components, and resources that make up a functional unit within the application. Prism modules can be developed, tested and deployed independently. They frequently consist of multiple assemblies and other resources packaged up into an easily deployable unit (for example in a XAP file). Prism provides infrastructure for the flexible deployment of modules. In the case of Silverlight, for example, modules can be downloaded with the core application, or can be downloaded in the background or on-demand.
Prism applications use a module catalog to tell it which modules to load. Module catalogs can be static (i.e. the list of modules is predetermined before run-time) or dynamic (i.e. the list of modules is determined at run-time and can take into account the user’s ID, role, configuration, installed modules, wind direction, etc). Dynamic module catalogs can be used to extend an application after its initial deployment. They can be implemented in many different ways. For example, you can build a dynamic catalog by reading a (local or remote) config file, or by using a web service that specifies the modules to load, or by scanning a particular folder to see what modules have been installed.
Once a module is loaded, Prism looks for an entry type that supports the IModule interface. This interface has only one method – Initialize – and can be used to provide any initialization logic that the module provides. Typically, this method is used to register types within the module with the DI container so that they can be accessed by other modules and the shell. Another common use of this method is to register Views contained within the module with UI regions. The module can do anything it needs to though, including kicking off background threads, making web service calls or downloading additional data or resources. Of course, you don’t have to provide any initialization logic if your module doesn’t require it.
Now, MEF too has the concept of a component catalog. When you import a type in MEF (i.e. you’ve expressed a dependency in one class to another class of a certain type), its resolves that type by looking in the MEF catalog which defines all of the types that are available for export (i.e. types that can be used by MEF to satisfy imports). This is a very powerful feature of MEF and allows you to express dependencies between components and have them fulfilled for you pretty much automatically, without having to explicitly register types with a DI container or having to resort to closely-coupled techniques like ‘new’ or CreateInstance. Note, I say ‘type’ here to keep things simple but MEF generalizes the relationship between importer and exporter using contracts, but contracts most often equate to types, and types can be interfaces.
So Prism module catalogs are really not the same as MEF catalogs since they’re specifying things at completely different levels of granularity. In addition, MEF does not provide any support for the packaging or conditional deployment of functional units within an application. However, there is clearly some overlap here since, at a lower level, Prism modules essentially contain a bunch of components that can import and export types so that they can be hooked up to components from other modules or the shell.
You can imagine using both Prism module catalogs and MEF catalogs together. The key here I think is for Prism to focus on the packaging, deployment and activation of coarse grained functional units (modules), as defined by either a static or dynamic module catalog, and to use MEF to support the flexible, meta-data driven composition of components within and across modules and the shell.
For example, imagine using Prism to build modules that represent functional units within an application and having it take care of their packaging and deployment via a dynamic or static module catalog. As each Prism module is loaded, the component dependencies within it (i.e. imports and exports) can be made available to MEF for component composition. In a sense, each module represents a catalog of components that MEF can use to fulfill and resolve component dependencies. There are other possibilities I am sure, and we’ll be exploring these as part of Prism 4.0…
Our goal for Prism 4.0 is to leverage MEF, and other .NET 4.0 and Silverlight 4.0 features, as much as possible so that we can provide a flexible and powerful environment for building modular, composite client applications on WPF and Silverlight 4.0. MEF is an exciting new technology and it’s great to see some level of support for loosely coupled component composition finally make it into the .NET Framework. I’m looking forward to exploring the possibilities here and I think it’s going to be pretty cool…
As well as MEF integration, for Prism 4.0 we’re looking at also providing more guidance on the ViewModel pattern, navigation, out of browser applications, developer/designer workflow, user experience patterns, visual studio templates, and a whole host of other areas. Which ones we tackle will depend on you, so as always, if you have any ideas or feedback, please let us know!