Architecture Overview

MEF’s design can be divided into three distinct layers. The container layer, which is most of the public API is available to the user; the primitives, which provides a layer of indirection so MEF won’t be tight coupled with a single approach to part discovery, imports/exports definitions and so forth; and finally our default implementation of the primitive layer that we call Attributed Programming Model, which relies on types and attributes for discovery and definition of imports/exports.

The container layer has no dependency on the attributed programming model, instead it solely work with the abstractions provided in the primitives layer. That makes possible to develop a completely different programming model, and have it working together with our default programming model, for example.

arch1.png

As a product of a major refactoring, the container is currently more of a coordinator and builder of a ExportProvider topology than anything else. The set of ExportProvider instances in use by a container instance is chained, so they can query each other for exports when satisfying dependencies. You can implement a custom ExportProvider to expose exports from any source – for example, WCF, an IoC Container, Remoting.

arch2.png

A whitepaper is available Hosting the .NET Composition Primitives.pdf discussing how the Primitives can be used independently of MEF.

Last edited Dec 22, 2009 at 5:11 AM by gblock, version 6

Comments

apo Feb 17, 2012 at 10:44 AM 
Which tool did you used for creating the architecture figures? They are looking nice.

bcraun Mar 16, 2011 at 8:47 PM 
Typo: "instead it solely work with the abstractions"

aL3891 Oct 28, 2009 at 10:28 AM 
a total nitpick, but in the white paper you define a class square, but the number of sides property returns 5, i assume you mean 4 :)

dmehers Apr 28, 2009 at 6:05 AM 
Typo: "which is most of the public API is available to the "