Guide de programmation MEF

Ajoutez manuellement chaque Composable Part dans la méthode Compose(), grâce à la méthode d'extension ComposeParts(). Dans l'exemple ci-dessous, une instance de EmailSender est ajoutée au CompositionContainer dans l'instance courante de la classe Program qui l'importe.

  private void Compose()
  {
    var container = new CompositionContainer();
    container.ComposeParts(this, new EmailSender());
  }

En utilisant le catalogue, le container prend en charge la création automatique des Parts plutôt que d'avoir à les rajouter manuellement. Pour cela, il faut créer un catalogue dans la méthode Compose(). Passez-le ensuite au constructeur du container.

Dans l'exemple ci-dessous, un AssemblyCatalog est créé avec comme paramètre du constructeur l'assemblage exécuté. Nous n'ajoutons pas directement une instance de EmailSender, elle sera découverte dans le catalogue.

  private void Compose()
  {
    var catalog = new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly());
    var container = new CompositionContainer(catalog);
    container.ComposeParts(this);
  }

Après avoir suivi ces différentes étapes, le code devrait maintenant ressembler à ceci:

  using System.ComponentModel.Composition;
  using System.ComponentModel.Composition.Hosting;
  using System.Reflection;
  using System;

  public class Program
  {
    [Import]
    public IMessageSender MessageSender { get; set; }

    public static void Main(string[] args)
    {
      Program p = new Program();
      p.Run();
    }

    public void Run()
    {
      Compose();
      MessageSender.Send("Message Sent");
    }

    private void Compose()
    {
      AssemblyCatalog catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
      var container = new CompositionContainer(catalog);
      container.ComposeParts(this);
    }
  }

  public interface IMessageSender
  {
    void Send(string message);
  }

  [Export(typeof(IMessageSender))]
  public class EmailSender : IMessageSender
  {
    public void Send(string message)
    {
      Console.WriteLine(message);
    }
  }

Lorsque ce code est compilé puis exécuté, l'application compose avec son import IMessageSender. Quand la méthode Send()est appelée, la console affiche donc « Message Sent ».

Pour des scénarios d'hébergement plus avancés, vous pouvez vous reporter à ce post : http://codebetter.com/blogs/glenn.block/archive/2010/01/15/hosting-mef-within-your-applications.aspx

Une ComposablePart est une unité composée au sein de MEF. Les Parts exportent des services qui sont essentiels à d'autres Composable Parts, et importent des services d'autres Composable Parts.

Dans le système de programmation de MEF, les attributs System.ComponentModel.Composition.Import et System.ComponentModel.Composition.Export sont utilisés afin de déclarer leurs imports et exports. Une Composable Part doit contenir au moins un export. Elle doit également être ajoutée explicitement au container ou créée via l'utilisation de catalogues. Les catalogues fournis par MEF identifient une Composable Part grâce à la présence de l'attribut d'export.

Les Composable Parts ne dépendent pas directement les unes des autres, elles passent des contrats qui sont des chaînes de caractères servant d'identifiants. Tous les exports ont des contrats, et tous les imports déclarent les contrats dont ils ont besoin. Le container utilise les informations du contrat pour lier les imports et les exports. Si le contrat n'est pas défini, MEF va implicitement utiliser le nom complet du type comme contrat. Si un type est utilisé comme contrat, c'est également son nom complet qui va servir.

De préférence un type devrait être utilisé pour un contrat, et pas une chaîne de caractères. Bien que les contrats puissent être une chaîne, cela peut mener à des ambiguïtés. Par exemple « Sender » peut interférer avec d'autres implémentations de « Sender » dans une librairie différente. Pour cette raison, si vous devez spécifier un contrat avec une chaîne de caractères, il est recommandé que le nom du contrat soit composé avec l'espace de noms incluant le nom de la société, par exemple « Contoso.Exports.Sender ».

Dans le code ci-dessous, tous les contrats sont équivalents :

namespace MEFSample 
{
  [Export]
  public class Exporter {...}

  [Export(typeof(Exporter))]
  public class Exporter1 {...}

  [Export("MEFSample.Exporter")]
  public class Exporter2 {...}
}

II-B-2-1. Contrats d'interface / abstraits▲

  [Export(typeof(IMessageSender))]
  public class EmailSender : IMessageSender {
    ...
  }

  [Export(typeof(IMessageSender))]  
  public class TCPSender : IMessageSender {
    ...
  }

  public class Notifier {
    [ImportMany]
    public IEnumerable<IMessageSender> Senders {get; set;}
    public void Notify(string message) {
      foreach(IMessageSender sender in Senders) 
        sender.Send(message);
    } 
  }

Un pattern commun lorsque l'on développe une application extensible avec MEF est de déployer un assemblage contenant les contrats utilisées par l'application hôte et ses extensions. Ces contrats seront donc les interfaces ou les classe abstraites faisant le lien entre les imports et les exports. Des assemblages de contrats supplémentaires pourront contenir des interfaces permettant de voir les métadonnées utilisées par les importateurs, ainsi que des attributs personnalisés d'exports.

Vous devez préciser le type d'interface (IMessageSender) qui sera exporté, sinon c'est le type lui-même (EmailSender) qui le sera.

Un export au niveau de la Composable Part est utilisé quand une Composable Part a besoin de s'exporter. Pour cela, il suffit de décorer la Composable Part avec l'attribut [System.ComponentModel.Composition.ExportAttribute], comme le montre le code ci-dessous.

[Export]
public class SomeComposablePart {
  ...
}

Les Parts peuvent également exporter leurs propriétés. L'export de propriétés est avantageux pour diverses raisons :

• cela permet d'exporter des types scellés tels que les types de bases de la CLR, ou d'autres types provenant de tiers ;
• cela permet de découpler l'export de sa création. Par exemple, vous pouvez exporter le HttpContext existant qui a été exécuté pour vous ;
• cela permet d'avoir une famille d'exportations liées dans la même Composable Part, comme la Composable Part DefaultSendersRegistry qui exporte un ensemble par défaut de senders comme propriétés.

Par exemple, vous pouvez avoir une classe Configuration qui exporte un entier avec un contrat « Timeout » :

  public class Configuration
  {
    [Export("Timeout")]
    public int Timeout
    {
      get { return int.Parse(ConfigurationManager.AppSettings["Timeout"]); }
    }
  }
  [Export]
  public class UsesTimeout	
  {
    [Import("Timeout")]
    public int Timeout { get; set; }
  }

Un export de méthode se produit lorsqu'une Part exporte l'une de ses méthodes. Les méthodes sont exportées comme des délégués qui sont spécifiés dans le contrat d'export. L'export de méthode possède plusieurs avantages :

• cela permet un contrôle plus précis de ce qui est exporté. Par exemple un moteur de règles est susceptible d'importer un set de méthodes extensibles ;
• cela protège l'appelant de toute connaissance du type ;
• ils peuvent être générés via du code, ce qui n'est pas permis pour les autres formes d'export.

L'export de méthodes ne peut avoir plus de quatre arguments, à cause d'une limitation du framework.

Dans l'exemple ci-dessous, la classe IMessageSender exporte sa méthode Send comme un délégué Action<String>. La classe Processor importe le même délégué.

  public class MessageSender
  {
    [Export(typeof(Action<string>))]
    public void Send(string message)
    {
      Console.WriteLine(message);
    }
  }

  [Export]
  public class Processor
  {
    [Import(typeof(Action<string>))]
    public Action<string> MessageSender { get; set; }

    public void Send()
    {
      MessageSender("Processed");
    }
  }

Vous pouvez également exporter et importer des méthodes en utilisant un simple contrat à chaîne de caractères :

  public class MessageSender
  {
    [Export("MessageSender")]
    public void Send(string message)
    {
      Console.WriteLine(message);
    }
  }

  [Export]
  public class Processor
  {
    [Import("MessageSender")]
    public Action<string> MessageSender { get; set; }

    public void Send()
    {
      MessageSender("Processed");
    }
  }

Quand vous faites un export de méthodes, il faut obligatoirement spécifier un type ou une chaîne de caractères de nom de contrat, et ne pas laisser le champ vide.

MEF supporte la capacité pour une classe mère/interface de définir des exports qui seront automatiquement hérités. C'est idéal pour l'intégration des frameworks souhaitant utiliser les fonctionnalités de découverte de MEF mais ne voulant pas que cela requiert de modifier du code existant. Pour mettre en place un export d'héritage, il suffit d'utiliser l'attribut System.ComponentModel.Composition.InheritedExportAttribute. Dans l'exemple ci-dessous, Logger implémente ILogger et est donc automatiquement exporté en tant qu'ILogger.

[InheritedExport]
public interface ILogger 
{
  void Log(string message);
}

public class Logger : ILogger 
{
  public void Log(string message);
}

MEF supporte la découverte de Composable Parts publiques et privées. Vous n'avez rien à faire pour activer ce comportement. Mais il est à noter que dans les environnements de confiance partielle/moyenne (incluant Silverlight), la composition de types privés n'est pas supportée.

Pour importer la valeur d'une propriété, il faut décorer la propriété avec l'attribut [System.ComponentModel.Composition.ImportAttribute]. Par exemple le code ci-dessous importe un IMessageSender.

  class Program
  {
    [Import]
    public IMessageSender MessageSender { get; set; }
  }

Vous pouvez aussi importer via des paramètres de constructeur. Cela signifie qu'au lieu d'ajouter des propriétés pour chaque import, il vous suffit d'ajouter des paramètres dans le constructeur. Pour cela, suivez ces étapes :

• Ajoutez un attribut [System.ComponentModel.Composition.ImportingConstructorAttribute] au constructeur
• Ajoutez un paramètre au constructeur pour chaque import

Le code ci-dessous importe un IMessageSender dans le constructeur de la classe Program :

  class Program
  {
    [ImportingConstructor]
    public Program(IMessageSender messageSender) 
    {
       ...
    }
  }

II-D-2-1. Import de paramètres▲

MEF supporte également l'import direct sur les champs.

  class Program
  {
    [Import]
    private IMessageSender _messageSender;
  }

L'import/export des membres privés (champs, propriétés, méthodes) est supporté en confiance totale, mais risque d'être problématique en confiance partielle/moyenne.

MEF vous permet de spécifier qu'un import est optionnel. Quand vous utilisez cette capacité, le container va fournir un export s'il y en a de disponible, sinon il va définir l'import avec Default(T). Pour rendre un import optionnel, définissez la valeur de la propriété AllowDefault de l'import à true.

[Export]
public class OrderController 
{
  private ILogger _logger;

  [ImportingConstructor]
  public OrderController([Import(AllowDefault=true)] ILogger logger) 
  {
    if(logger == null)
      logger = new DefaultLogger();
    _logger = logger;
  }
}

La classe OrderController importe optionnellement logger en tant que paramètre du constructeur. Si logger n'est pas défini par l'import, le champ _logger sera défini avec une instance de DefaultLogger. Dans le cas contraire, c'est l'import de logger qui est utilisé.

En plus des imports simples, vous pouvez importer des collections en utilisant l'attribut ImportMany. Cela signifie que des instances du contrat spécifié seront importées depuis le container.

Les Parts MEF supportent aussi la recomposition. Cela signifie que si de nouveaux exports sont disponibles dans le container, la collection sera automatiquement mise à jour.

Dans l'exemple ci-dessous, la classe Notifier importe une collection de IMessageSender. Cela signifie que si trois exports de IMessageSender sont disponibles dans le container, ils seront tous les trois ajoutés à la propriété Senders durant la composition.

 public class Notifier 
 {
    [ImportMany(AllowRecomposition=true)]
    public IEnumerable<IMessageSender> Senders {get; set;}

    public void Notify(string message) 
    {
      foreach(IMessageSender sender in Senders)
      {
        sender.Send(message);
      }
    } 
  }

Dans différentes situations il peut être important pour votre classe d'être notifiée quand MEF a fini avec le processus d'import de l'instance de votre classe. C'est ce cas qu'implémente l'interface [System.ComponentModel.Composition.IPartImportsSatisfiedNotification]. Elle ne possède qu'une seule méthode : OnImportsSatisfied, qui est appelée quand tous les imports pouvant être satisfait le sont.

 public class Program : IPartImportsSatisfiedNotification
 {
    [ImportMany]
    public IEnumerable<IMessageSender> Senders {get; set;}

    public void OnImportsSatisfied() 
    {
      // when this is called, all imports that could be satisfied have been satisfied.
    } 
  }

Considérons l'interface IMessageSender introduite plus haut. Supposons que nous en avons plusieurs implémentations et qu'elles ont des différences pouvant être relevées par la classe important ces implémentations.

Dans notre exemple, le type de transport des messages ainsi que le fait qu'il soit sécurisé sont des informations importantes que l'importateur veut connaître.

II-F-1-1. Utiliser l'attribut ExportMetadata▲

public interface IMessageSender
{
    void Send(string message);
}

[Export(typeof(IMessageSender))]
[ExportMetadata("transport", "smtp")]
public class EmailSender : IMessageSender
{
    public void Send(string message)
    {
        Console.WriteLine(message);
    }
}

[Export(typeof(IMessageSender))]
[ExportMetadata("transport", "smtp")]
[ExportMetadata("secure", null)]
public class SecureEmailSender : IMessageSender
{
    public void Send(string message)
    {
        Console.WriteLine(message);
    }
}

[Export(typeof(IMessageSender))]
[ExportMetadata("transport", "phone_network")]
public class SMSSender : IMessageSender
{
    public void Send(string message)
    {
        Console.WriteLine(message);
    }
}

II-F-1-2. Utiliser un attribut d'export personnalisé▲

[MetadataAttribute]
[AttributeUsage(AttributeTargets.Class, AllowMultiple=false)]
public class MessageSenderAttribute : ExportAttribute
{
    public MessageSenderAttribute() : base(typeof(IMessageSender)) { }
    public MessageTransport Transport { get; set; }
    public bool IsSecure { get; set; }
}

public enum MessageTransport
{
    Undefined,
    Smtp,
    PhoneNetwork,
    Other
}

[MessageSender(Transport=MessageTransport.Smtp)]
public class EmailSender : IMessageSender
{
    public void Send(string message)
    {
        Console.WriteLine(message);
    }
}

[MessageSender(Transport=MessageTransport.Smtp, IsSecure=true)]
public class SecureEmailSender : IMessageSender
{
    public void Send(string message)
    {
        Console.WriteLine(message);
    }
}

[MessageSender(Transport=MessageTransport.PhoneNetwork)]
public class SMSSender : IMessageSender
{
    public void Send(string message)
    {
        Console.WriteLine(message);
    }
}

Les importateurs ont accès aux métadonnées attachées aux exports.

II-F-2-1. Utiliser des métadonnées fortement typées▲

public interface IMessageSenderCapabilities
{
    MessageTransport Transport { get; }
    bool IsSecure { get; }
}

[Export]
public class HttpServerHealthMonitor
{
    [ImportMany]
    public Lazy<IMessageSender, IMessageSenderCapabilities>[] Senders { get; set; }

    public void SendNotification()
    {
        foreach(var sender in Senders)
        {
            if (sender.Metadata.Transport == MessageTransport.Smtp && 
                sender.Metadata.IsSecure)
            {
                var messageSender = sender.Value;
                messageSender.Send("Server is fine");
                
                break;
            }
        }
    }
}

II-F-2-2. Utiliser des métadonnées faiblement typées▲

[Export]
public class HttpServerHealthMonitor
{
    [ImportMany]
    public Lazy<IMessageSender, IDictionary<string,object>>[] Senders { get; set; }

    public void SendNotification()
    {
        foreach(var sender in Senders)
        {
            if (sender.Metadata.ContainsKey("Transport") && sender.Metadata["Transport"] == MessageTransport.Smtp && 
                sender.Metadata.ContainsKey("Issecure") && Metadata["IsSecure"] == true)
            {
                var messageSender = sender.Value;
                messageSender.Send("Server is fine");
                
                break;
            }
        }
    }
}

II-F-2-3. Le filtrage des métadonnées et l'attribut DefaultValueAttribute▲

public interface IMessageSenderCapabilities
{
    MessageTransport Transport { get; }
    [DefaultValue(false)];
    bool IsSecure { get; }
}

La classe [System.ComponentModel.Composition.Hosting.AssemblyCatalog] permet de découvrir les exports présents dans un assemblage donné.

var catalog = new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly());

La classe [System.ComponentModel.Composition.Hosting.DirectoryCatalog] permet de découvrir les exports des assemblages présents dans un répertoire donné.

var catalog = new DirectoryCatalog("Extensions");

Si un chemin relatif est utilisé, il sera complété à partir du répertoire racine du domaine d'application courant.

Le catalogue de répertoire ne scanne qu'une seule fois le répertoire, il ne rafraîchit pas ses données dès qu'un changement se produit dans le répertoire. Mais il est possible d'implémenter votre propre système de détection de modification, par exemple avec un FileSystemWatcher, et d'appeler la méthode Refresh du catalogue afin qu'il scan à nouveau le répertoire et qu'il recompose les imports/exports.

var catalog = new DirectoryCatalog("Extensions");
//logique de détection de modification du répertoire
catalog.Refresh();

Ce catalogue n'est pas supporté par Silverlight.

Quand un AssemblyCatalog ou un DirectoryCatalog seuls ne suffisent pas, vous pouvez les combiner grâce à la classe [System.ComponentModel.Composition.Hosting.AggregateCatalog]. Elle va combiner plusieurs catalogues en un seul . Un usage typique est d'y ajouter l'assemblage courant ainsi qu'un DirectoryCatalog vers un dossier d'extensions. Vous pouvez passer une collection de catalogues au constructeur de AggregateCatalog ou les ajouter un à un via sa propriété Catalogs.

var catalog = new AggregateCatalog(
  new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly()), 
  new DirectoryCatalog("Extensions"));

La classe [System.ComponentModel.Composition.Hosting.TypeCatalog] permet de découvrir des exports de types donnés.

var catalog = new TypeCatalog(typeof(type1), typeof(type2), ...);

La version Silverlight de MEF inclut le DeploymentCatalog pour télécharger dynamiquement des XAPs distants. Ce catalogue sera décrit en détail dans la partie de MEF pour Silverlight.

Pour utiliser un catalogue dans un container, il suffit de le passer en tant que paramètre du constructeur du container.

var container = new CompositionContainer(catalog);

La « shareability » d'une Part est définie via un ensemble de politiques de création au niveau de la classe en utilisant l'attribut PartCreationPolicy. Il accepte les valeurs suivantes :

• Shared : l'auteur de la Part signifie à MEF qu'au plus une instance de la Part existe par container ;
• NonShared : l'auteur de la Part signifie à MEF que chaque requête d'export concernant la Part recevra une nouvelle instance de la Part ;
• Any ou aucune valeur : l'auteur de la Part permet à la Part d'être utilisée aussi bien en tant que « Shared » que « NonShared ».

La politique de création peut être définie sur une Part en utilisant l'attribut [System.ComponentModel.Composition.PartCreationPolicyAttribute] :

[PartCreationPolicy(CreationPolicy.NonShared)]
[Export(typeof(IMessageSender))]
public class SmtpSender : IMessageSender
{
}

Le container sera toujours le propriétaire des Parts qu'il crée. En d'autres termes, la propriété n'est jamais transférée à l'acteur à l'origine de la requête via un import ou un export.

La police de création de Parts peut aussi servir pour définir un critère d'import. Il suffit de spécifier une valeur de l'énumération CreationPolicy pour la valeur RequiredCreationPolicy :

[Export]
public class Importer
{
    [Import(RequiredCreationPolicy=CreationPolicy.NonShared)]
    public Dependency Dep { get; set; }
}

Cette fonctionnalité peut s'avérer utile pour des scénarios où la shareability d'une Part est importante pour la classe à l'origine de l'import. Par défaut RequiredCreationPolicy a la valeur Any, donc des Parts ayant une politique de création à Shared ou NonShared peuvent être importées.

Le tableau suivant résume le comportement d'import en fonction de la politique de création :

Quand les deux parties définissent Any, le résultat est une Part partagée.

L'instance d'un container est généralement celle qui va diriger le cycle de vie de ses Parts. Les instances des Parts créées par le container ont leur cycle de vie conditionné par celui du container. La seule façon de mettre fin au cycle de vie d'un container est de le disposer. Les implications de cette action sont les suivantes :

• La méthode Dispose des Parts implémentant IDisposable sera appelée
• Les références des Parts contenues dans le container seront supprimées
• Les Parts partagées seront disposées et supprimées
• Les exports différés ne fonctionneront plus après que le container ait été disposé
• L'utilisation des Parts pourra lever l'exception System.ObjectDisposedException

Nous croyons que le Garbage Collector .NET est la meilleure chose qui soit pour nettoyer proprement. Néanmoins, nous devons aussi fournir un container avec un comportement déterministe. Ainsi, le container ne gardera pas les anciennes références des Parts qu'il a créées à moins d'être dans un des cas suivants :

• la Part est Shared ;
• la Part implémente IDisposable ;
• un ou plusieurs imports sont configurés pour la recomposition.

Dans ces cas-là, une référence à la Part est gardée. Combiné au fait que vous pouvez avoir des Parts non partagées et continuer à requêter le container, la demande de mémoire peut devenir un problème. Afin de réguler ce problème, vous pouvez vous appuyer sur les stratégies exposées dans les deux paragraphes suivants.

Certains types d'applications, comme les web apps ou les web services varient beaucoup des applications de bureau. Elles sont plus susceptibles de reposer sur des opérations en lots et à courte durée de vie. Par exemple un service windows peut regarder directement et une seule fois si un nombre prédéterminé de fichiers sont présents et lancer une opération batch afin de modifier leur format. Les opérations web peuvent être limitées à une opération par requête.

Pour ce genre de scénarios, vous devez utiliser des containers enfants (ceci est expliqué dans le paragraphe suivant) ou libérer rapidement le graphe de l'objet. Celui-ci permet au container de disposer et de supprimer les références des Parts non partagées dans le graphe de l'objet - jusqu'à ce qu'il atteigne une Part partagée.

Afin de libérer le plus rapidement possible le graphe de l'objet vous devez appeler la méthode ReleaseExport de la classe CompositionContainer :

var batchProcessorExport = container.GetExport<IBatchProcessor>();

var batchProcessor = batchProcessorExport.Value;
batchProcessor.Process();

container.ReleaseExport(batchProcessorExport);

Le schéma ci-dessous représente un graphe d'objets et montre quelles Parts seraient libérées (références supprimées, disposées) et celles qui resteraient intactes :

Comme la Part racine n'est pas partagée, aucune référence ne sera conservée par le container. Continuons en vérifiant les exports servis à la Part racine. Dep 1 est à la fois non partagée et disposable, donc la Part est disposée et sa référence sera supprimée du container. Dep 2 aura le même comportement. Cependant, l'export de Dep 2 est laissé intact car il est partagé. Ainsi d'autres Parts peuvent l'utiliser.

Vous n'avez pas besoin de faire plusieurs passages pour libérer les Parts pouvant l'être, l'implémentation traverse le graphe de façon profonde dès la première fois.

Une autre façon de résoudre le problème est d'utiliser la hiérarchie des containers. Vous pouvez créer des containers et les connecter à un container parent, faisant d'eux des containers enfants.

A moins de fournir un catalogue différent au container enfant il ne sera pas d'une grande aide car l'instanciation est basée sur celle du parent.

Ce que vous devez donc faire c'est filtrer le catalogue parent sur la base d'un critère qui va séparer le groupe de Parts créé par le parent de celui créé par l'enfant. Ou alors vous devez spécifier un nouveau catalogue qui va exposer un groupe de Parts qui sera créé par le container enfant. Comme le container enfant est censé avoir une durée de vie courte, ses Parts seront libérées et disposées avant celles de son parent.

Une approche commune est d'avoir les Parts partagées créées par le container parent et les Parts non partagées par le container enfant. Comme les Parts partagées peuvent dépendre des exports fournis par les Parts non partagées. Le catalogue principal devra contenir toutes les Parts. Le container enfant devra donc mettre en place un filtre sur le catalogue principal pour n'avoir que les Parts non partagées.

Pour plus d'information à ce sujet, veuillez vous reporter au paragraphe sur les catalogues filtrés.

L'ordre de disposition n'est nullement garanti. Cela signifie que vous ne devez pas tenter d'utiliser un import dans votre méthode Dispose(). Par exemple :

[Export]
public class SomeService : IDisposable
{
    [Import]
    public ILogger Logger { get; set; }
    
    public void Dispose()
    {
         Logger.Info("Disposing"); // might throw exception!
    }
}

L'utilisation de l'instance de l'import logger dans l'implémentation de la méthode Dispose peut engendrer un problème étant donné que l'implémentation du contrat ILogger peut aussi implémenter l'interface IDisposable et donc qu'elle est peut-être déjà disposée.

Toutes les Parts ne sont pas créées par un container. Vous pouvez également lui ajouter et lui enlever des Parts. Ce process déclenche la composition et peut démarrer la création des Parts répondant aux dépendances des Parts ajoutées récursivement. Quand une Part ajoutée est supprimée, MEF est assez intelligent pour libérer les ressources associées et disposer les Parts non partagées utilisées par la Part ajoutée.

MEF ne va jamais prendre la propriété d'une instance créée par vous, mais il peut avoir la propriété d'une Part qu'il a créé afin de satisfaire les imports de votre instance.

using System;
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using System.ComponentModel.Composition.Primitives;

class Program
{
    static void Main(string[] args)
    {
        var catalog = new AssemblyCatalog(typeof(Program).Assembly);
        var container = new CompositionContainer(catalog);
        var root = new Root();

        // add external part
        container.ComposeParts(root);

        // ... use the composed root instance

        // removes external part
        batch = new CompositionBatch();
        batch.RemovePart(root);
        container.Compose(batch);
    }
}

public class Root
{
    [Import(RequiredCreationPolicy = CreationPolicy.NonShared)]
    public NonSharedDependency Dep { get; set; }
}

[Export, PartCreationPolicy(CreationPolicy.NonShared)]
public class NonSharedDependency : IDisposable
{
    public NonSharedDependency()
    {
    }

    public void Dispose()
    {
        Console.WriteLine("Disposed");
    }
}

• quand une recomposition a lieu, les instances de la collection / tableau sont remplacées par de nouvelles instances, ce n'est pas une mise à jour. Dans l'exemple du dessus, si un nouveau IMessageSender apparaît, Senders sera complètement remplacé par un nouveau tableau. Cela a pour but de faciliter la Thread-safety ;
• la recomposition est valide pour quasiment tous les types d'imports supportés : champs, propriétés et collections, mais pas pour les paramètres de constructeur ;
• si votre type implémente l'interface [System.ComponentModel.Composition.IPartImportsSatisfiedNotification], prenez en compte le fait que la méthode ImportCompleted sera également appelée à chaque recomposition.

Dans Silverlight, la recomposition utilise une règle spéciale à cause du partitionnement de l'application. Pour plus de détails, reportez vous au chapitre sur le DeploymentCatalog dans Silverlight.

Le code suivant permet de récupérer une instance du contrat Root :

var container = new CompositionContainer(new AssemblyCatalog(typeof(Program).Assembly));
Root partInstance = container.GetExportedValue<Root>();

Si vous avez un export ayant un nom de contrat différent du nom de la classe, vous devez utiliser la surcharge suivante :

[Export("my_contract_name")]
public class Root
{
}

var container = new CompositionContainer(new AssemblyCatalog(typeof(Program).Assembly));
Root partInstance = container.GetExportedValue<Root>("my_contract_name");

GetExport retrouve une référence instanciée avec retard d'un export. L'utilisation de la propriété Value de l'export va forcer la création de l'instance. L'instanciation successive de la propriété Value de l'export retournera la même instance, que la Part ait un cycle de vie Shared ou Non-Shared.

Lazy<Root> export = container.GetExport<Root>();
var root = export.Value; //create the instance.

Cette méthode fonctionne exactement comme GetExportedValue mais ne lèvera pas d'exception dans le cas où aucune correspondance ne serait trouvée.

var root = container.GetExportedValueOrDefault<Root>(); // may return null

II-M-1-1. Problèmes liés au rejet▲

Une des implications de la composition stable est que les Parts rejetées ne vont tout simplement pas apparaître.

Parce que les Parts sont interdépendantes, une Part rejetée peut entraîner une chaîne de rejet des Parts dépendantes.

Trouver la « Root Cause » d'une cascade de rejet comme celle-ci peut être compliqué.

Parmi les samples de la preview 9 de MEF (téléchargeables dans la partie « Liens »), le sample CompositionDiagnostics est un prototype de librairie de diagnostic qui peut être utilisé afin de traquer les problèmes de composition.

Les deux fonctions basiques qui sont implémentées permettent à l'état de rejet d'une Part d'être inspecté et de sortir le contenu du catalogue avec les informations d'analyse du statut et de la root cause.

II-M-1-2. Dump Composition State▲

Pour un diagnostic complet, la composition entière doit être sortie sous forme de texte :

 

Sélectionnez

var cat = new AssemblyCatalog(typeof(Program).Assembly);
using (var container = new CompositionContainer(cat))
{
var ci = new CompositionInfo(cat, container);
CompositionInfoTextFormatter.Write(ci, Console.Out);
}

La sortie peut s'avérer intéressante, incluant les « primary rejection » devinées et l'analyse des problèmes courant comme la non-correspondance de l'identité du type, la non-correspondance de la politique de création et les métadonnées requises manquantes :

Il y a ici assez d'information pour diagnostiquer correctement les problèmes les plus courants.

II-M-1-3. Trouver les root causes probables▲

var fooInfo = ci.GetPartDefinitionInfo(typeof(Foo));

II-M-1-4. Débogage des proxies▲

Les types MEF comme ComposablePartCatalog peuvent être inspectés grâce au débuggeur :

MEFX (téléchargeable via les previews de MEF sur codeplex ou dans la partie « Liens » de cet article) est un utilitaire permettant la réalisation de routines de diagnostic affichant les informations sur les Parts directement dans la console.

C:\Users\...\CompositionDiagnostics> mefx /?

  /?

      Print usage.

  /causes

      List root causes - parts with errors not related to the rejection of other parts.

  /dir:C:\MyApp\Parts

      Specify directories to search for parts.

  /exporters:MyContract

      List exporters of the given contract.

  /exports

      Find exported contracts.

  /file:MyParts.dll

      Specify assemblies to search for parts.

  /importers:MyContract

      List importers of the given contract.

  /imports

      Find imported contracts.

  /parts

      List all parts found in the source assemblies.

  /rejected

      List all rejected parts.

  /type:MyNamespace.MyType

      Print details of the given part type.

  /verbose

      Print verbose information on each part.

Le paramètre /parts liste toutes les Parts de la composition :

C:\Users\...\CompositionDiagnostics> mefx /dir:..\MefStudio /parts

Designers.CSharp.Commands

Designers.BasicComponentFactory

Designers.CSharpFormFactory

...

Les paramètres /rejected et /causes vont respectivement afficher les informations sur les Parts rejetées et sur les root causes probables.

Le paramètre /verbose permet d'afficher les informations détaillées des Parts pouvant être récupérées :

C:\Users\...\CompositionDiagnostics> mefx /dir:..\MefStudio /type:Designers.BasicComponentFactory /verbose

[Part] Designers.BasicComponentFactory from: DirectoryCatalog (Path="..\MefStudio")

  [Export] Designers.BasicComponentFactory (ContractName="Contracts.HostSurfaceFactory")

  [Import] Contracts.HostSurfaceFactory.propertyGrid (ContractName="Contracts.IPropertyGrid")

    [Actual] ToolWindows.PropertyGridWindow (ContractName="Contracts.IPropertyGrid") from: ToolWindows.PropertyGridWindow from: DirectoryCatalog (Path="..\MefStudio")

  [Import] Contracts.HostSurfaceFactory.Commands (ContractName="System.Void(Contracts.HostSurface)")

    [Actual] Designers.CSharp.Commands.Cut (ContractName="System.Void(Contracts.HostSurface)") from: Designers.CSharp.Commands from: DirectoryCatalog (Path="..\MefStudio")

    [Actual] Designers.CSharp.Commands.Copy (ContractName="System.Void(Contracts.HostSurface)") from: Designers.CSharp.Commands from: DirectoryCatalog (Path="..\MefStudio")

    [Actual] Designers.CSharp.Commands.Paste (ContractName="System.Void(Contracts.HostSurface)") from: Designers.CSharp.Commands from: DirectoryCatalog (Path="..\MefStudio")

Il est important de savoir que cet utilitaire ne peut analyser que des assemblages MEF générés avec une version compatible de MEF. Par exemple, mefx.exe présent sur CodePlex et donc généré avec la version de MEF présente sur CodePlex n'est pas compatible avec la version de MEF présente dans le framework .NET, et vice-versa.

Les informations produites durant la composition peuvent être vues dans la fenêtre de sortie du débuggeur, ou en s'attachant à la source de trace « System.CompositionModel.Composition".

La classe CompositionContainer ne fournit pas de surcharges non-génériques parmi les méthodes GetExport*, comme GetExportedValue par exemple :

// not supported
object value = container.GetExportedValue(type);

A la place, utilisez la surcharge de GetExports(ImportDefinition) :

IEnumerable<Export> matching = container.GetExports(
  new ContractBasedImportDefinition(
    AttributedModelServices.GetContractName(type),
    AttributedModelServices.GetTypeIdentity(type),
    Enumerable.Empty<string>(),
    ImportCardinality.ExactlyOne,
    false,
    false,
    CreationPolicy.Any));
object value = matching.Single().Value;

Les containers imbriqués sont parfois utilisés afin de manager le cycle de vie et les portées partagées.

Pour plus de détails sur les catalogues filtrés, veuillez vous reporter au chapitre adéquat.

Lorsque des containers enfants sont créés, ils prennent généralement deux paramètres de constructeur - leur propre catalogue et leur parent (un CompositionContainer passé en tant que ExportProvider).

En utilisant cette configuration, toutes les références sont requêtées via le plus imbriqué des containers enfants.

Si une dépendance peut être satisfaite depuis le catalogue du container, elle le sera. Le cycle de vie de Parts résultants de cette dépendance sera lié au cycle de vie du container enfant, et toutes les dépendances de ces Parts seront satisfaites depuis le même container (récursivement, en utilisant cet algorithme).

Quand un container enfant ne peut satisfaire la dépendance via son propre catalogue, il appelle celui de son parent. Si la dépendance est satisfaite grâce à son parent, le cycle de vie de la Part résultante sera lié à celui du parent. Les dépendances de cette Part seront satisfaites par le parent, plus aucun appel ne sera fait à l'enfant.

La clé pour réussir à mettre en place toute la configuration est le catalogue fourni à chaque container.

Comme règle générale, toutes les Parts NonShared devraient pouvoir être créées à n'importe quel niveau et devraient donc apparaître dans les catalogues de tous les containers.

Dans la hiérarchie des containers, les Parts partagées sont un peu plus compliquées. Le partage est relatif au container qui a créé la Part, donc une Part partagée dans le catalogue d'un container enfant sera partagée au sein de ce container spécifique. Les autres containers qui peuvent voir la même Part dans leur catalogue créeront et partageront leurs propres instances.

Cela signifie qu'à l'intérieur d'un seul graphe d'objets, il est possible d'avoir plus d'une instance d'une Part partagée (une dans un enfant, une autre accessible via une dépendance résolue par le parent).