Contratos, vistas y adaptadores
En este tema se describen las vistas y los adaptadores, los segmentos que son comunes a ambos extremos de la canalización del complemento y el contrato que utilizan el host y el complemento. En la ilustración siguiente se muestran los segmentos de la canalización de complementos.
Canalización de complementos
.png "Modelo de canalización de complementos.")
Para obtener ejemplos de código, vea Tutorial: Habilitar la compatibilidad con versiones anteriores al cambiar el host y Tutorial: Pasar colecciones entre hosts y complementos.
Contratos
El primer paso para desarrollar la canalización de la comunicación es definir un contrato que debe derivarse de la interfaz IContract. Si el host y el complemento están cargados en dominios de aplicación independientes, existirá un límite de aislamiento entre el complemento y el host de la canalización. Un contrato es una interfaz sin versiones que define el protocolo de los tipos que se comunican a través de límites de aislamiento. Cuando se utilizan contratos para establecer la comunicación a través de un límite de aislamiento, el modelo del complemento impide que las implementaciones del host y del complemento de los tipos sufran pérdidas al cruzar el límite, lo que causaría problemas con las versiones.
Los objetos que deben comunicarse a través de los dominios de aplicación tienen que ser remotos. Para obtener más información acerca de los objetos remotos, vea Remotable and Nonremotable Objects.
La clase ContractBase proporciona una implementación predeterminada de los miembros de IContract. La interfaz del contrato también puede heredar de esta clase.
Requisitos de los contratos
Los contratos deben atenerse a un conjunto de requisitos para garantizar que todos los tipos expresados dentro de los contratos son seguros, que se pueden crear versiones de ellos y que pueden cruzar el límite de aislamiento entre el host y el complemento.
Los contratos deben heredar de IContract y utilizar sólo los tipos siguientes:
Otro contrato que se derive de IContract.
Tipos de datos primitivos: tipos enteros y booleanos.
Los tipos serializables definidos en el ensamblado del contrato.
Los tipos serializables definidos en Mscorlib.dll, como Int32 y DateTime.
Tipos de referencia serializables que estén sellados. Por ejemplo, puede pasar un objeto String a través del límite de aislamiento porque es un tipo de referencia serializable que está sellado.
Las enumeraciones que están definidas en el contrato o en Mscorlib.dll.
Objetos AddInToken.
Matrices de cualquiera de los tipos enumerados anteriormente, a excepción de las matrices de contratos.
Para pasar colecciones de objetos, utilice tipos que implementen la interfaz IList<T> genérica, como las colecciones List<T> y ArrayList. Para pasar estas colecciones a través del límite de aislamiento, debe convertirlas temporalmente en la interfaz IListContract<T>. En el tema Tutorial: Pasar colecciones entre hosts y complementos se muestra cómo se pasan las colecciones.
Para generar la canalización, el contrato que representa el complemento debe identificarse con el atributo AddInContractAttribute.
El paso siguiente en el desarrollo de la canalización consiste en crear los segmentos del adaptador y la vista de ambos extremos de la canalización. Estos segmentos proporcionan al complemento y a la aplicación host vistas de sus respectivos modelos de objetos y adaptadores que convierten esas vistas en el contrato, y viceversa.
Vistas
La vista de complemento del host y la vista de host del complemento son ensamblados que contienen interfaces o clases abstractas que representan las vistas de la otra parte implicada y de los tipos que fluyen entre ambas partes. Las vistas no dependen de los contratos utilizados para comunicarse entre ambas partes. Las vistas también separan el complemento y el host de la implementación del otro. Esto permite cambiar los adaptadores y el contrato sin comprometer al host o al complemento.
Para generar la canalización, el tipo de la vista de complemento que el complemento implementa o hereda se identifica mediante el atributo AddInBaseAttribute y se denomina "base del complemento". La vista de host no necesita ningún atributo de detectabilidad porque esta vista se pasa a los métodos FindAddIns.
Adaptadores
Los adaptadores del extremo del complemento y del extremo del host son ensamblados que contienen las clases de adaptadores que se utilizan para realizar la conversión entre las vistas y el contrato. El término "extremo" hace referencia a la parte de la canalización en la que se encuentra un adaptador. En función de la dirección de la llamada, el adaptador convertirá una vista en un contrato o un contrato en una vista. Si tiene llamadas en ambas direcciones (es decir, el host llama al complemento y el complemento llama al host), tendrá dos adaptadores en cada extremo de la canalización. Existen, por tanto, dos tipos de adaptadores:
Adaptador de vista a contrato.
Una clase de un ensamblado del adaptador que convierte una vista en un contrato. Esta clase implementa el contrato llamando a la vista que se pasó a su constructor y sus referencias se calculan a través del límite como un contrato. Esta clase debe heredar ContractBase e implementar el contrato.
Adaptador de contrato a vista.
Una clase del ensamblado del adaptador que convierte un contrato en un vista. Esta clase implementa o hereda el segmento de la vista que está convirtiendo, en función de si la vista es una interfaz o un tipo base abstracto, e implementa los miembros de la vista llamando al contrato que se pasa al constructor del adaptador.
Para generar la canalización, debe identificar la clase del adaptador de conversión con el atributo AddInAdapterAttribute e identificar la clase del adaptador del host con el atributo HostAdapterAttribute.
No es necesario que los adaptadores sean públicos.