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 |
|---|---|
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. |
Viene descritto l'utilizzo dell'interoperabilità COM e di platform invoke. |
|
Vengono descritti i concetti e le regole di conversione dell'interoperabilità COM. |
|
Vengono descritti il servizio di marshalling di interoperabilità, la sua relazione con il marshalling COM e il ruolo svolto nelle comunicazioni remote. |