Considerazioni di progettazione per l'interoperabilità

In questo argomento vengono descritte le differenze esistenti tra modelli di programmazione gestiti e non gestiti. Per consigli e informazioni sulle strategie di interoperatività in fase di progettazione, vedere Compilazione di componenti COM per l'interoperabilità e Compilazione di componenti .NET Framework per l'interoperabilità.

È necessario che tutte le chiamate effettuate tra il codice gestito e non gestito negozino i requisiti imposti dal rispettivo modello di programmazione. Il modello di programmazione gestito e quello non gestito differiscono sotto molti aspetti. Nella tabella riportata di seguito sono illustrate le caratteristiche distintive di ciascun modello.

Caratteristica	Modello non gestito	Modello gestito	Dettagli
Modello di codifica	Basato su interfaccia	Basato su oggetto	La comunicazione con gli oggetti non gestiti avviene sempre tramite interfacce, mentre classi e oggetti gestiti possono passare direttamente i dati senza implementare le interfacce. Per impostazione predefinita, un'interfaccia di classe viene generata dall'interoperabilità COM per esporre la funzionalità gestita mediante un'interfaccia a COM quando non ne viene implementata una dall'oggetto o dalla classe.
Identità	GUID	Nomi sicuri	I GUID identificano un tipo non gestito specifico e non forniscono informazioni sul percorso a tale tipo. I nomi sicuri sono costituiti da un nome di assembly univoco oltre a un nome di tipo. Poiché il tipo viene specificato dal nome di assembly in modo univoco, è possibile riutilizzare un nome di tipo in più assembly. Tramite l'assembly vengono anche introdotte in un tipo gestito una chiave editore, una versione e informazioni sul percorso. I servizi di interoperabilità generano GUID e sono denominati in modo sicuro come richiesto.
Meccanismo di gestione degli errori	HRESULT	Eccezioni	Un HRESULT viene di solito restituito dai metodi COM per indicare se la chiamata è o meno riuscita. Il codice gestito incorpora le eccezioni. Per impostazione predefinita, con l'interoperabilità COM viene eseguito il mapping delle eccezioni gestite sugli HRESULT di errore.
PODS (Plain Old Data Structures, Semplici strutture di dati non aggiornati)	Struttura	Struttura gestita derivata dall'oggetto	Non è possibile utilizzare platform invoke per restituire strutture o classi per valore se contengono un costruttore. In generale, i tipi definiti dall'utente che contengono elementi non PODS devono essere restituiti per riferimento. Per PODS si intende strutture di dati che contengono solo insiemi passivi di valori di campo, in base alla definizione data dallo standard 14882 ISO/IEC relativo al linguaggio di programmazione C++. Non contengono costruttori, operatori di assegnazione di copia, distruttori o membri dati non statici che non siano a loro volta PODS.
Compatibilità dei tipi	Standard binario	Standard dei tipi	I tipi variano tra codice gestito e non gestito, nonché tra i linguaggi.
Definizione dei tipi	Libreria dei tipi	Metadati	Come è noto a chi ha familiarità con le librerie dei tipi, queste contengono solo tipi pubblici. Una libreria dei tipi è inoltre facoltativa. Nel modello gestito di programmazione le informazioni sui tipi sono obbligatorie per tutti i tipi. I servizi di interoperabilità forniscono strumenti per la conversione delle librerie dei tipi in metadati in assembly e di metadati in librerie dei tipi.
Indipendenza dai tipi	Non indipendente dai tipi	Eventualmente sicuro	I compilatori non gestiti non prevedono il controllo dei tipi sui tipi di puntatore, esponendo il codice ad attività potenzialmente dannose. In generale, per il codice gestito viene richiesto un livello di attendibilità superiore. È possibile continuare a utilizzare i puntatori nel codice gestito, sebbene il codice presenti limitazioni dovute al comportamento non sicuro. I servizi di interoperabilità consentono di impedire l'accesso al codice non gestito da parte di codice gestito non attendibile.
Controllo delle versioni	Immutabile	Adattabile	Le interfacce COM sono immutabili. Se si modifica un'interfaccia, è necessario rinominarla con un nuovo GUID. I tipi gestiti possono evolversi, pur mantenendo lo stesso nome.

Ad alcune caratteristiche dei modelli di programmazione sono associate entità che è possibile visualizzare, come le librerie dei tipi e i metadati. Alcune possono essere passate come argomenti, quali i GUID e i nomi sicuri. Altre ancora sono più concettuali e il loro impatto sulla progettazione dell'applicazione deve essere indubbiamente preso in considerazione, ma non esiste un mapping diretto tra il modello gestito e quello non gestito per tali caratteristiche.

Argomenti correlati

Titolo	Descrizione
Compilazione di componenti COM per l'interoperabilità	Vengono descritte le strategie di interoperabilità in fase di progettazione per i componenti COM.
Compilazione di componenti .NET Framework per l'interoperabilità	Vengono descritte le strategie di interoperabilità in fase di progettazione per i componenti .NET Framework.
Interoperabilità con codice non gestito	Viene descritto l'utilizzo dell'interoperabilità COM e di platform invoke.
Interoperabilità COM avanzata	Vengono descritti i concetti e le regole di conversione dell'interoperabilità COM.
Marshalling di interoperabilità	Vengono descritti il servizio di marshalling di interoperabilità, la sua relazione con il marshalling COM e il ruolo svolto nelle comunicazioni remote.