MEF: Pièces de chargement (plug-ins) qui ont des propriétés différentes

Question

Bref historique:

Mon équipe (MEF) a décidé d'utiliser Framework de Microsoft Managed Extensibility afin de fournir un modèle extensible pour ajouter de nouveaux "fournisseurs" dans notre système.

Cela nous permet de brancher de nouveaux fournisseurs tiers avec une relative facilité.

Note: J'ai été impressionné par la facilité d'utilisation et d'utilisation de MEF.

Ma question:

Étant donné que ces fournisseurs ont souvent des propriétés différentes qui leur sont associés, lors du chargement de ces fournisseurs dans le système lors de l'exécution, nous avons besoin d'accéder aux fournisseurs des flux de données et les propriétés.

Quelle approche devrait-on adopter pour travailler avec les plug-ins du fournisseur en raison des propriétés différentes? Notant qu'ils font tous un travail similaire.

Ma solution:

Créer une interface que les fournisseurs doivent se conformer à, entraînant une « enveloppe » en cours de création autour de chacun des fournisseurs 3ème partie résultant dans un modèle de programmation d'interface cohérente/ pour travailler avec chaque fournisseur. Plug-in = source de données tierce (fournisseur) + Implémentation d'interface commune.

+ ve: Pas besoin d'un "plug" dynamique à base de réflexion plus complexe pour lesdits plug-ins.

-ve: Avoir à écrire un wrapper pour chaque fournisseur. (Nous devons ajouter les balises d'exportation MEF, quel que soit)

De plus Note:

Pour moi serait le plus simple, mais on me dit l'approche d'interface/wrapper pour enquêter sur une approche basée sur la réflexion qui peut utiliser la réflexion afin de découvrir les propriétés à l'exécution qui peuvent être exposées au système. Je ne suis pas en faveur d'une solution par rapport à une autre, mais je serais intéressé à entendre les pensées de la communauté (dont la plupart sont plus expérimentés que moi).

Merci.

Answer 1

Il n'est pas très clair de savoir de quelles "propriétés" et "flux de données" parlez-vous, mais quand même.

Oui, une interface commune est toujours une bonne chose. Et puisque vous avez tous ces « propriétés » et ce, ce que je propose:

interface IProperty 
{ 
    string Name { get; } 
    object Value { get; } 
} 

interface IDataStreamProvider 
{ 
    Stream OpenStream(); 
} 

interface IPlugin 
{ 
    ReadOnlyCollection<IProperty> Properties { get; } 

    ReadOnlyCollection<IDataStreamProvider> DataStreams { get; } 
} 

En parlant de « emballages »: Je ne comprends pas l'intention de ceux-ci.Tous les plug-ins tiers doivent mettre en œuvre IPlugin interface et doivent être décorées avec soit ExportAttribute ou PluginAttribute comme dans ceci:

class PluginAttribute : ExportAttribute 
{ 
    public PluginAttribute() : 
     base(typeof(IPlugin)) 
    { 
    } 
} 

La réflexion doit être évitée autant que possible en raison des problèmes de maintenabilité.

Answer 2

Ce que j'ai fait pour ajouter de telles informations est de créer des attributs personnalisés pour les plugins, puis de les lire avec MEF quand les plugins sont chargés. Vous pouvez ajouter n'importe quoi dans la classe d'attributs, comme des noms, enums, ints, d'autres chaînes, et il est assez facile à utiliser. Mais attention, la nouvelle preview6 a changé quelques points dans la manière dont ils sont gérés.

[MetadataAttribute] 
public class MyMetadataAttribute : Attribute 
{ 
    public MyType MyUsage { get; set; } 
} 

public interface IMyMetadataView 
{ 
    MyType MyUsage { get; } 
} 

public enum MyType 
{ 
    Undefined, 
    TypeOne, 
    TypeTwo 
} 

Et puis dans le plugin, vous pouvez le définir comme ça ...

[Export(typeof(IMyInterface))] 
[MyMetadataAttribute(MyUsage = MyType.TypeOne)] 
public class PluginClass: IMyInterface 
{ 
} 

Vous devez ajouter des choses à l'importation puis aussi

[ImportMany(AllowRecomposition = true)] 
public IEnumerable<Lazy<IMyInterface, IMyMetadataView>> plugins { get; set; } 

Vous pouvez alors utiliser la Données directement pour chaque plug-in

Encore une fois, c'est la manière d'utiliser preview 6 qui est sorti en Juillet.

Answer 3

En fait, dans Preview 6, nous avons une exportation non scellée et vous permet de créer un attribut d'exportation personnalisé qui inclut des métadonnées, évitant ainsi aux auteurs de pièces d'ajouter une exportation distincte. Tous nos attributs d'importation sont également non scellés. RuleAttribute ci-dessus exporte IRule et permet également de fournir des métadonnées Name.

L'utilisation serait alors la suivante:

[Rule("AddOneRule", "Adds one to the value")] 
public class AddOneRule { 
} 

HTH Glenn