Contratti, visualizzazioni e adattatori
In questo argomento vengono descritti visualizzazioni e adattatori, i segmenti comuni a entrambi i lati della pipeline del componente aggiuntivo e il contratto utilizzato dall'host e dal componente aggiuntivo. Nell'illustrazione seguente sono mostrati i segmenti della pipeline del componente aggiuntivo.
Pipeline di componenti aggiuntivi
.png "Modello pipeline di componenti aggiuntivi")
Per esempi di codice, vedere Procedura dettagliata: abilitazione della compatibilità con le versioni precedenti in base alle modifiche dell'host e Procedura dettagliata: passaggio di insiemi tra host e componenti aggiuntivi.
Contratti
Il primo passaggio nello sviluppo della pipeline di comunicazione consiste nella definizione di un contratto che deve essere derivato dall'interfaccia IContract. Se l'host e il componente aggiuntivo vengono caricati in domini applicazione separati, esiste un limite di isolamento tra il lato del componente aggiuntivo della pipeline e il lato host della pipeline. Un contratto è un'interfaccia senza controllo delle versioni che definisce il protocollo per la comunicazione dei tipi oltre un limite di isolamento. Grazie all'utilizzo dei contratti per comunicare oltre un limite di isolamento, il modello di componente aggiuntivo impedisce che le implementazioni dei tipi dell'host e del componente aggiuntivo si disperdano oltre il limite generando problemi relativi al controllo della versione.
Gli oggetti che devono essere comunicati tra i domini applicazione devono essere gestibili da remoto. Per ulteriori informazioni sugli oggetti gestibili da remoto, vedere Remotable and Nonremotable Objects.
La classe ContractBase fornisce un'implementazione predefinita dei membri IContract. L'interfaccia del contratto può ereditare anche questa classe.
Requisiti dei contratti
I contratti devono rispettare un insieme di requisiti per assicurare che tutti i tipi espressi al loro interno siano sicuri, possano essere sottoposti al controllo delle versioni e possano passare oltre il limite di isolamento tra host e componenti aggiuntivi.
I contratti devono ereditare da IContract e devono utilizzare solo i tipi seguenti:
Altri contratti derivati da IContract.
Tipi di dati primitivi: numeri interi e tipi booleani.
Tipi serializzabili definiti nell'assembly del contratto.
Tipi serializzabili definiti in Mscorlib.dll, ad esempio Int32 e DateTime.
Tipi di riferimento sealed, serializzabili. È ad esempio possibile passare un oggetto String attraverso il limite di isolamento perché è un tipo di riferimento sealed, serializzabile.
Enumerazioni definite nel contratto o in Mscorlib.dll.
Oggetti AddInToken.
Matrici di uno qualsiasi dei tipi elencati prima, fatta eccezione per una matrice di contratti.
Per passare insiemi di oggetti, utilizzare tipi che implementano l'interfaccia IList<T> generica, ad esempio gli insiemi List<T> e ArrayList. Per passare questi insiemi oltre il limite di isolamento, è necessario convertirli temporaneamente nell'interfaccia IListContract<T>. Nell'argomento Procedura dettagliata: passaggio di insiemi tra host e componenti aggiuntivi viene illustrato come passare gli insiemi.
Per costruire la pipeline, è necessario identificare il contratto che rappresenta il componente aggiuntivo con l'attributo AddInContractAttribute.
Il passaggio successivo nello sviluppo della pipeline prevede la creazione della visualizzazione e dei segmenti di adattatore per entrambi i lati della pipeline. Tali segmenti forniscono all'applicazione host e al componente aggiuntivo le visualizzazioni dei rispettivi modelli a oggetti, nonché adattatori in grado di convertire tali visualizzazioni in contratto e viceversa.
Visualizzazioni
La visualizzazione del componente aggiuntivo dell'host e la visualizzazione host del componente aggiuntivo sono assembly contenenti interfacce o classi astratte che ne rappresentano le visualizzazioni reciproche e quelle dei tipi che fluiscono tra loro. Le visualizzazioni non dipendono dai contratti utilizzati per le comunicazioni interne. Esse inoltre separano il componente aggiuntivo e l'host dalle rispettive implementazioni. In questo modo gli adattatori e il contratto possono essere modificati senza influire sull'host o sul componente aggiuntivo.
Per costruire la pipeline, il tipo nella visualizzazione del componente aggiuntivo che tale componente implementa o eredita viene identificato dall'attributo AddInBaseAttribute e viene chiamato base del componente aggiuntivo. La visualizzazione host non richiede un attributo per l'individuazione in quanto viene passata ai metodi FindAddIns.
Adattatori
Gli adattatori sul lato host e sul lato del componente aggiuntivo sono assembly contenenti classi di adattatori utilizzate per eseguire la conversione da visualizzazione a contratto e viceversa. Il termine "lato" si riferisce al lato della pipeline sul quale risiede l'adattatore. A seconda della direzione della chiamata, l'adattatore esegue la conversione da una visualizzazione in un contratto o da un contratto in una visualizzazione. In presenza di chiamate in entrambe le direzioni, ovvero l'host esegue la chiamata al componente aggiuntivo e quest'ultimo esegue la chiamata all'host, si avranno due adattatori su ciascun lato della pipeline. Di conseguenza, sono disponibili due tipi di adattatori:
Adattatore visualizzazione-contratto.
Classe in un assembly dell'adattatore che converte una visualizzazione in un contratto. Tale classe implementa il contratto chiamando la visualizzazione passata al costruttore e viene sottoposta a marshalling oltre il limite come contratto. La classe deve ereditare ContractBase e implementare il contratto.
Adattatore contratto-visualizzazione.
Classe nell'assembly dell'adattatore che converte una visualizzazione in un contratto. Questa classe implementa o eredita il segmento di visualizzazione che sta convertendo, a seconda se la visualizzazione è un'interfaccia o un tipo di base astratto, e implementa i membri della visualizzazione chiamando il contratto passato al costruttore dell'adattatore.
Per costruire la pipeline, la classe dell'adattatore sul lato componente aggiuntivo deve essere identificata applicando l'attributo AddInAdapterAttribute e la classe dell'adattatore sul lato host deve essere identificata applicando l'attributo HostAdapterAttribute.
Non è necessario che gli adattatori siano pubblici.