This project has moved. For the latest updates, please go here.

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 6:11 AM by gblock, version 6

Comments

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

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

aL3891 Oct 28, 2009 at 11: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 7:05 AM 
Typo: "which is most of the public API is available to the "