MEF: What and why

So it’s been almost two years working for Microsoft and feels like several years. Not because I was able to accomplish much – I haven’t – but that things go in a different pace here. I learned to understand why that is, and how Microsoft can afford to pay smart people to solve tough problems. MEF is one of them.

As a hardcore developer I’ve always approach projects as the ‘what’ and the feature set. As a PM I learned to have a broader view of things. I’ve also learned to lay down plans and really think through before writing a single line of code, but that deserves another post altogether. It took me quite some time to get past MEF as just a framework and understand where it fits in the bigger picture. I realize, though, that people in community are still asking the wrong questions.

MEF is an IoC Container? That’s undeniable. It makes use of the same Inversion of Control principle that governs all IoC Containers out there. In the past, we tried hard to position it as not an IoC Container, but that was the wrong approach. What we really meant to say was that it’s not comparable to the usual suspects. Instead, it’s a very specialized one. If you want concrete points (applies to MEF out of the box):

· We do not have the same extensibility points

· We do not support manual/explicit wiring

· We do not support any interception mechanism

· We do not have any self-contained reusable extensibility mechanism, such as Windsor’s Facilities

Behavior wise MEF also differs from the usual suspects. We value explicitness over conventions. We value discovery over registration code. We value static analyzability as a mean to support a rich tooling story.

The scenarios

Before saying “you guys suck” please allow me to explain you that MEF – as with most things that come from MS - is scenario-driven. We selected a handful of scenarios for version 1.0 based mostly on partner’s requirements and feedback and it was engineered to meet those. I’ll share a bit about them so you can understand where we came from, and where does MEF fit.

Open ended applications

IoC Containers are really engineered for “closed systems”. You know beforehand the set of components that will make your app, you control how they are wired up (bindings) and their configuration. In an open ended system you just know the set of components you are shipping but once that is deployed and new extensions start to be added, you cross your fingers and hope for the best.

With that in mind, several decisions were made to make MEF a reliable technology for these kinds of scenarios. You certainly don’t want VS to crash if you happen to add a malfunction extension.

Stable composition

Stable composition is a feature introduced to deal exactly with this situation. It tries to pre-compose a graph and rejects pieces that will lead to a part that cannot be set up to its minimum requirements. If you were to use MEF as a standard IoC Container, though, this will eventually bite your development experience, especially if you’re not aware of it.

Reusing “parts” across application models

Imagine writing common parts that you could reuse in a Wpf, Silverlight, Console apps and ASP.NET apps. Of course, this part would have to make some diligence on the kind of dependencies it has from the external world. Any container specific behavior introduced by extension points or optional integrations could hurt this story. If parts were to depend on the container being set up to support a specific feature, then the reuse story would be compromised. That said, I believe it’s fair game to depend or support upon orthogonal/cross-cutting functionality.

Design-time diagnostics

Even though most people dislike MEF’s attributes, it allows us to build a rich tooling story that could help you to write extensions, predict errors and so forth. This is intended a productivity boost, not as a pain-reliever.

Beyond what: why?

Stepping back from the technology, MEF is a great tool for – at very minimum – two reasons:

· It provides a ubiquitous way to expose extension points and consume extensions

· It presents a minimal set of concepts that people should learn in order to deal with extensions

Provided that, in time, the MEF gets the adoption it deserves from framework builders to app builders, we will see an interesting side effect: an ecosystem of extensions with degrees of reusability based on interdependencies. I believe that would be a huge win for us, the .net community, and look forward for this day.

I also believe MEF is a great choice for framework builders. I intend to write a series of blog posts exemplifying this. Keep watching!