Utilisation de MEF dans la couche Service (WCF)

Question

Jusqu'à présent, j'ai trouvé que MEF se passe bien avec la couche de présentation avec les avantages suivants.

a. DI (injection de dépendance)

b. Extensibilité de tiers (Notez que toutes les parties impliquées doivent utiliser MEF ou avoir besoin de wrappers)

c. Découverte automatique de pièces (extensions)

d. MEF permet de baliser les extensions avec des métadonnées supplémentaires qui facilitent l'interrogation et le filtrage riches.

e. Peut être utilisé pour résoudre les problèmes de versionnement avec "DLR et C# références dynamiques" ou "type embedding"

Veuillez me corriger si je me trompe.

Je fais la recherche sur l'utilisation de MEF dans la couche Service avec WCF. Pls partager votre expérience en utilisant ces deux ensemble et comment MEF vous aide?

Merci,

Nils

---

Mise à jour

Voici ce que jusqu'à présent mon résultat de la recherche. Merci à Matthew d'y avoir contribué. MEF pour les services de base - le coût des modifications ne justifie pas les avantages. De plus, cette décision est importante et peut affecter la couche de service de façon bonne ou mauvaise, et nécessite donc beaucoup d'études. MEF V2 (En attente d'une version stable) pourrait être mieux dans ce cas mais peu inquiet à propos de l'utilisation de MEF V1 ici.

MEF pour le service de fonction effectue - MEF peut ajouter la valeur, mais il est très spécifique à la fonction de service. Nous devons approfondir l'exigence de service pour prendre cette décision. L'étude est un processus continu, donc chacun partagera s'il vous plaît vos pensées et votre expérience.

Answer 1

Je pense que toute situation qui bénéficierait de la séparation des préoccupations, bénéficierait de IoC. Le problème que vous rencontrez ici est de savoir comment vous devez utiliser MEF dans votre service. Serait-ce pour le service de base lui-même, ou une fonction que le service effectue. Par exemple, si vous voulez injecter des services dans vos services WCF, vous pouvez utiliser quelque chose de similaire à l'exemple MEF for WCF sur CodePlex. Je n'ai pas trop regardé dedans, mais essentiellement il enveloppe l'emplacement du service via un IInstanceProvider, vous permettant de personnaliser la façon dont votre type de service est créé. Je ne sais pas si elle prend en charge l'injection de constructeur (ce qui serait ma préférence) si ...?

Si le composant de service WCF n'est pas où vous voulez utiliser MEF, vous pouvez toujours tirer parti de MEF pour créer des sous-ensembles de composants utilisés par le service. Récemment, pour la société pour laquelle je travaille, nous avons reconstruit notre processus de devis, et j'ai construit un modèle de calcul de workflow flexible, dans lequel les unités de flux de travail sont des pièces composées MEF qui peuvent être branchées si nécessaire.La partie importante ici consisterait à gérer la façon dont votre CompositionContainer est utilisé par rapport à la durée de vie de votre service WCF (par exemple, le comportement de Singleton, etc.). Ceci est très important si vous décidez de créer un nouveau conteneur à chaque fois (la création de conteneur est assez bon marché, alors que la création de catalogue peut être coûteuse).

Espérons que ça aide.

Answer 2

Je travaille sur une solution où les parties MEF que je veux utiliser à travers les appels WCF sont stockées dans un singleton au niveau de l'application. Tout est hébergé dans IIS. Les services sont décorés pour être compatibles avec asp.net.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] 

Dans Global.asax, j'importe les pièces. Après l'initialisation du catalogue et du conteneur, je copie les objets importés dans ma classe singleton. Après l'initialisation du catalogue et du conteneur.

container.ComposeParts(this); 
foreach (var option in AvailableOptions) 
    OptionRegistry.AddOption(option); 

EDIT:

Ma classe de Registre:

public static class OptionRegistry 
{ 
    private static List<IOption> _availableOptions= new List<IOption>(); 

    public static void AddOption(IOption option) 
    { 
     if(!_availableOptions.Contains(option)) 
      _availableOptions.Add(option); 
    } 

    public static List<IOption> GetOptions() 
    { 
     return _availableOptions; 
    } 
} 

Cela fonctionne, mais je veux le faire threadsafe donc je posterai cette version une fois qu'il est fait.

Thread-safe Registre:

public sealed class OptionRegistry 
{ 

    private List<IOptionDescription> _availableOptions; 
    static readonly OptionRegistry _instance = new OptionRegistry(); 

    public static OptionRegistry Instance 
    { 
     get { return _instance; } 
    } 


    private OptionRegistry() 
    { 
     _availableOptions = new List<IOptionDescription>(); 
    } 


    public void AddOption(IOptionDescription option) 
    { 
     lock(_availableOptions) 
     { 
      if(!_availableOptions.Contains(option)) 
       _availableOptions.Add(option); 
     } 
    } 

    public List<IOptionDescription> GetOptions() 
    { 
     return _availableOptions; 
    } 

} 

Answer 3

Un peu je me demandais il y a comment je pourrais créer un service Web WCF qui obtenir toutes ses dépendances câblés par le MEF, mais que je ne reviendrai pas besoin d'écrire un seul ligne de ce code de fil dans ma classe de service. Je voulais aussi que ce soit complètement basé sur la configuration, donc je pourrais juste prendre ma solution générique pour le prochain projet sans avoir à faire de changements de code.

Une autre exigence que j'avais était que je devrais être en mesure de tester unitaire le service et mock out ses dépendances différentes d'une manière facile.

je suis venu avec une solution qui ive blogué sur ici: Unit Testing, WCF and MEF

Espérons que aidera les gens à essayer de faire la même chose.