Contrats, vues et adaptateurs
Cette rubrique décrit les vues et les adaptateurs, les segments communs aux deux côtés du pipeline du complément, et le contrat utilisé à la fois par l'hôte et le complément. L'illustration suivante montre les segments du pipeline du complément.
Pipeline de complément
.png "Modèle de pipeline de complément.")
Pour des exemples de code, consultez Procédure pas à pas : activation de la compatibilité descendante lorsque votre hôte change et Procédure pas à pas : passage de collections entre des hôtes et des compléments.
Contrats
La première étape du développement d'un pipeline de communication est de définir un contrat qui doit être dérivé de l'interface IContract. Si l'hôte et le complément sont chargés dans des domaines d'application séparés, une limite d'isolation sépare les côtés complément et hôte du pipeline. Un contrat est une interface de non versioning qui définit le protocole pour communiquer des types à travers une limite d'isolation. En utilisant des contrats pour communiquer à travers une limite d'isolation, le modèle de complément empêche la divulgation des implémentations des types par l'hôte et le complément au-delà de la limite et d'éventuels problèmes de versioning.
Les objets qui doivent être communiqués à travers des domaines d'application doivent être accessibles à distance. Pour plus d'informations sur les objets accessibles à distance, consultez Remotable and Nonremotable Objects.
La classe ContractBase fournit une implémentation par défaut des membres IContract. Votre interface de contrat peut également hériter de cette classe.
Spécifications en matière de contrats
Les contrats doivent respecter un jeu de spécifications pour garantir que tous les types exprimés dans les contrats sont sûrs, associés à des versions pouvant être gérées et qu'ils peuvent traverser la limite d'isolation qui sépare les hôtes et les compléments.
Les contrats doivent hériter de IContract et utiliser uniquement les types suivants :
d'autres contrats dérivés de IContract ;
des types de données primitifs : entiers et types booléens ;
des types sérialisables définis dans l'assembly de contrat ;
des types sérialisables définis dans Mscorlib.dll, comme Int32 et DateTime ;
des types référence sérialisables sealed ; par exemple, vous pouvez passer un objet String à travers la limite d'isolation parce qu'il s'agit d'un type référence sérialisable sealed ;
des énumérations définies dans le contrat ou dans Mscorlib.dll ;
des objets AddInToken ;
des tableaux de chacun des types répertoriés ci-dessus, à l'exception d'un tableau de contrats.
Pour passer des collections d'objets, utilisez des types qui implémentent l'interface IList<T> générique, comme les collections List<T> et ArrayList. Pour passer ces collections au-delà de la limite d'isolation, convertissez-les temporairement en interface IListContract<T>. La rubrique Procédure pas à pas : passage de collections entre des hôtes et des compléments montre comment passer des collections.
Pour construire le pipeline, le contrat qui représente le complément doit être identifié avec l'attribut AddInContractAttribute.
L'étape suivante du développement du pipeline est de créer les segments de la vue et de l'adaptateur pour les deux côtés du pipeline. Ces segments fournissent à l'application hôte et au complément des vues de leurs modèles objet respectifs et fournissent des adaptateurs qui convertissent ces vues vers le contrat et à partir de ce dernier.
Vues
La vue complément de l'hôte et la vue hôte du complément sont des assemblys qui contiennent des interfaces ou des classes abstraites représentant leurs vues respectives et les types qui circulent entre eux. Les vues ne dépendent pas des contrats utilisés pour communiquer entre elles. Les vues séparent également le complément et l'hôte de leurs implémentations respectives. Cela permet la modification des adaptateurs et du contrat sans affecter l'hôte ou le complément.
Pour construire le pipeline, le type de la vue du complément que le complément implémente ou dont il hérite est identifié par l'attribut AddInBaseAttribute et est appelé la base du complément. La vue hôte ne requiert pas d'attribut pour la détectabilité, parce qu'elle est passée aux méthodes FindAddIns.
Adaptateurs
Les adaptateurs des côtés complément et hôte sont des assemblys qui contiennent des classes d'adaptateurs utilisées pour effectuer des conversions vers les vues et le contrat et à partir de ces derniers. Le terme « côté » fait référence au côté du pipeline sur lequel un adaptateur réside. Selon la direction de l'appel, l'adaptateur effectue la conversion d'une vue en contrat ou d'un contrat en vue. En présence d'appels dans les deux directions (autrement dit, l'hôte appelle le complément et le complément appelle l'hôte), vous aurez deux adaptateurs de chaque côté du pipeline. Par conséquent, il existe deux types d'adaptateurs :
Adaptateur de vue en contrat
Classe d'un assembly d'adaptateur qui convertit une vue en un contrat. Cette classe implémente le contrat en appelant la vue passée à son constructeur et elle est marshalée à travers la limite en tant que contrat. Cette classe doit hériter de ContractBase et implémenter le contrat.
Adaptateur de contrat en vue
Classe de l'assembly d'adaptateur qui convertit un contrat en vue. Cette classe implémente le segment de vue qu'il convertit ou en hérite, selon que la vue est une interface ou un type de base abstrait, et implémente les membres de la vue en appelant le contrat passé au constructeur de l'adaptateur.
Pour créer le pipeline, vous devez identifier la classe de l'adaptateur côté complément en appliquant l'attribut AddInAdapterAttribute et identifier la classe de l'adaptateur côté hôte en appliquant l'attribut HostAdapterAttribute.
Les adaptateurs ne doivent pas forcément être publics.