*Dependency resolution* - (Based on experiments) MEF first tries to satisfy imports based on Metadata and Contract. If that fails MEF tries to satisfy import with first matching Contract (sorted alphabetically by Type name).

%width=320px% http://wiki.kiv.zcu.cz/uploads/UvodDoKomponent/mefarch2.png | *Fig*: _Namespaces of the different Containers._

%width=600px%Attach:arch2.png

%lfloat% http://wiki.kiv.zcu.cz/uploads/UvodDoKomponent/MEFPrimitives.png
%width=500px%Attach:mefarch3v2.png
*Fig*: _Overall view of the primitive classes._

%lfloat% http://wiki.kiv.zcu.cz/uploads/UvodDoKomponent/MEFAPM.png
%width=300px%Attach:mefarch4.png
*Fig:* _Class Hierarchy of different types of Catalogs._

%lfloat% http://wiki.kiv.zcu.cz/uploads/UvodDoKomponent/MEFContainer.png

%width=280px% http://wiki.kiv.zcu.cz/uploads/UvodDoKomponent/mefarch2.png | *Fig*: _Class Hierarchy of the Containers._

Complete article [[In-Depth analysis of MEF Architecture -> https://kishore1021.wordpress.com/window-8-winrt/in-depth-analysis-of-mef-architecture/]] same at [[codeproject -> http://www.codeproject.com/Articles/102884/MEF-Architecture-in-Detail]]

*TypeCatalog : Catalog containing discovered types
*AssemblyCatalog: Catalog containing parts that are discovered in an assembly.
*DirectoryCatalog: Catalog containing parts that are discovered in the directory.
*AggregareCatalog: It holds the collection of Catalogs.

%width=500px%Attach:mefarch2.png
*Fig*: _Class Hierarchy of the Containers._

*CompositionContainer* – The composition container, “CompositionContainer”, is present in the namespace System.ComponentModel.Composition.Hosting. The container contains a collection of parts that were either created by the container or added to it by the application. Parts contain a collection of exports (services it offers including itself) and imports (services it consumes) with imports being optional or required. Once a Part has been added to the container, it can be composed. During composition, the container satisfies all of a Part’s imports based on available exports. If a required import cannot be satisfied, then composition will fail.

A CompositionContainer object serves two major purposes in an application. First, it keeps track of which parts are available for composition and what their dependencies are, and serves as the context for any given composition. Second, it provides the methods by which the application can initiate composition, get instances of composed parts, or fill the dependencies of a composable part. Parts can be made available to the container either directly or through the Catalog property. All the parts discoverable in this ComposablePartCatalog are available to the container to fulfill imports, along with any parts added directly.

*ComposablePartExportProvider* – This provider is responsible for retrieving exports from part catalogs. It contains a collection of parts. However the parts in its collection are created from the PartDefinitions it queries rather than being explicitly added to it. Also, it contains a CompositionEngine for satisfying the imports on its parts.

*CatalogExportProvider* – Retrieves exports from a catalog.

*AggregatingExportProvider* – This provider is a composite of other providers that it contains, and is used for providing a topology of EPs. Whenever this provider is queried, it will query the providers within. The internal query behavior varies depending on the cardinality of the ImportDefinition that is passed in. It queries its children. The container uses an AggregatingEP internally which contains a ComposablepartEP, a CatalogEP and/or a custom provider if one was passed in during its construction. AggregatingEPs can also be nested without a problem.

h3. Primitives:

Namespace: *System.ComponentModel.Composition.Primitives*

The Primitives is an abstraction layer. This layer provides a layer of indirection so MEF won’t be tight coupled with a single approach to part discovery, imports/exports definitions. Actually, catalogs provide the available components to the container through this layer. The primitives provide APIs for describing, creating, and using components.

%width=500px%Attach:mefarch3.png
*Fig*: _Overall view of the primitive classes._

The primitives represent component instances capable of being wired together, component definitions with rich meta data and common query interfaces for component catalogs. The role of the Primitives is to specify components that can be wired together to create useful software.

*ComposablePart* is an instance of live executing software component. The ComposablePart specifies its dependencies and capabilities through import and export respectively. The ComposablePart describes its own imports though ImportDefinition and exports through ExportDefinition

*ExportDefinition* is a structure comprising of a string-based ContractName and a dictionary of additional information called metadata. Each ExportDefnition attached to a composablepart describes the individual capability (service offered) of the part. Metadata is useful to perform some additional querying or filtering on the part.

*ImportDefinition* It describes the dependency of the part. IsRecomposable is useful to indicates whether the import definition can be satisfied multiple times. IsPrerequisite indicates whether the import definition must be satisfied before a part can start producing exported objects.

*ComposablePartDefinition* describes the kinds of ComposablePart that can be created in a given system. It defines an abstract base class for composable part definitions, which describe and enable the creation of ComposablePart objects. CreatePart method creates a new instance of a part that the ComposablePartDefinition describes.

*ComposablePartCatalog* The ComposablePartDefinitions are grouped together into ComposablePartCatalogs. Using IQueryable<ComposablePartDefinition> Parts property, we can get the part definitions that are contained in the catalog.



h3. Attributed Programming Model

*Namespace:* System.ComponentModel.Composition.Hosting

We can directly use the above mentioned Primitives in our applications to perform composition and other tasks but it is very laborious task. So there should be a way for the developers to interact with the primitives using some programming model. APM optimize the task of mapping a class or interface and members to a ComposablePartDefinition with exports and imports.

%width=500px%Attach:mefarch4.png
*Fig:* _Class Hierarchy of different types of Catalogs._

The Attributed Programming Model is the implementation of the primitive layer. Different catalogs can provide components that are defined using different programming models. The default programming model for MEF is the attributed programming model which uses the Import and Export attributes. The TypeCatalog, AssemblyCatalog, and DirectoryCatalog that ship with MEF use this programming model. The ability to use a different programming model provides a lot of flexibility. Instead of using the Import and Export attributes, you could have your imports and exports defined based on a convention or an external configuration file. You could also write a catalog where the components are defined using a dynamic language such as IronPython or IronRuby. And you can use an AggregateCatalog to combine all of these catalogs and use them all together in the same container.

The primary interfaces to the Attributed Programming Model are:

TypeCatalog : Catalog containing discovered types
AssemblyCatalog: Catalog containing parts that are discovered in an assembly.
DirectoryCatalog: Catalog containing parts that are discovered in the directory.
AggregareCatalog: It holds the collection of Catalogs.
Well, that’s the high level view of the MEF internal structure. As mentioned earlier, the developer can use this framework using any programming model. In .Net 4.0, Microsoft provided the Attributed Programming Model to the developers to code the applications using MEF. Primitives are an abstraction layer, so tomorrow you can move from APM to any other model easily.

Complete description [[In-Depth analysis of MEF Architecture -> https://kishore1021.wordpress.com/window-8-winrt/in-depth-analysis-of-mef-architecture/]] same at [[codeproject -> http://www.codeproject.com/Articles/102884/MEF-Architecture-in-Detail]]

Attach:arch1_thumb.png
*Fig*: _Different layers in the Managed Extensions Framework._

h3. Container
The namespaces of the different containers are as follows:

-> {} System.ComponentModel.Composition.Hosting.AggregateExportProvider
-> {} System.ComponentModel.Composition.Hosting.CatalogExportProvider
-> {} System.ComponentModel.Composition.Hosting.ComposablePartExportProvider
-> {} System.ComponentModel.Composition.Hosting.CompositionContainer

%width=700px%Attach:arch2.png
*Fig*: _The chained set of ExportProvider instances in use by a container instance, so they can query each other for exports when satisfying dependencies_

Complete description [[In-Depth analysis of MEF Architecture -> https://kishore1021.wordpress.com/window-8-winrt/in-depth-analysis-of-mef-architecture/]] same at [[codeproject -> https://kishore1021.wordpress.com/window-8-winrt/in-depth-analysis-of-mef-architecture/]]