Cenni preliminari sui metadati

I metadati sono utilizzati per descrivere tipi in fase di esecuzione (classi, interfacce e tipi di valore), campi e metodi, nonché l'implementazione interna e le informazioni sul layout utilizzate da Common Language Runtime (CLR). Il runtime utilizza i metadati per eseguire la compilazione JIT di Microsoft Intermediate Language (MSIL), caricare le classi, eseguire codice e interagire con l'ambiente COM classico o nativo. I metadati vengono forniti con tutti i componenti di Common Language Runtime e sono disponibili per il runtime, gli strumenti e i servizi.

In questa panoramica sono incluse le sezioni seguenti:

• API dei metadati

• Confronto con i servizi di reflection

• Ambito

• Controllo degli errori

• Argomenti correlati

API dei metadati

Tutte le operazioni di modifica dei metadati vengono eseguite tramite l'API dei metadati, che isola un client (strumenti e servizi) dalle strutture dei dati sottostanti. L'API dei metadati fornisce un formato di persistenza modulare che consente di trasferire in modo trasparente rappresentazioni binarie del runtime, librerie dei tipi classiche COM e altri formati da e verso la memoria.

Nell'API dei metadati sono incluse interfacce che generano e importano metadati. Un client può generare o importare metadati nei seguenti modi:

• I compilatori e gli strumenti generano i metadati chiamando le API di generazione. I metadati vengono generati durante il processo di compilazione e collegamento. Gli strumenti RAD generano i metadati come parte della procedura di compilazione di componenti o applicazioni. I membri dell'API scrivono e leggono da strutture dei dati in memoria. Al momento del salvataggio, tali strutture in memoria vengono compresse e rese permanenti in formato binario nell'unità di compilazione di destinazione (file con estensione obj), nel file eseguibile (con estensione exe) o nel file binario dei metadati autonomo. Quando più unità di compilazione vengono collegate per formare un file EXE o una DLL, i membri delle API di generazione forniscono un metodo che consente di unire le sezioni dei metadati di ogni unità in un singolo file binario dei metadati integrato.

• Il caricatore e altri servizi e strumenti di runtime importano i metadati chiamando i membri delle API per ottenere informazioni sui componenti, in modo che attività quali il caricamento e l'attivazione possano essere completate.

Torna all'inizio

Confronto con i servizi di reflection

L'API dei metadati consente l'accesso ai metadati di un componente senza che la classe debba essere caricata dal runtime. L'API è progettata specificamente per ottimizzare le prestazione e ridurre al minimo il sovraccarico. Il motore dei metadati rende disponibili i dati ma evita di fornire l'accesso diretto alle strutture dei dati all'interno della memoria. Quando invece una classe viene caricata in fase di esecuzione, il caricatore importa i metadati nelle proprie strutture dei dati che è possibile esplorare utilizzando i servizi di reflection del runtime.

I servizi di reflection svolgono una quantità di lavoro maggiore rispetto all'API dei metadati. Ad esempio, verificano automaticamente la gerarchia di ereditarietà per ottenere informazioni su metodi e sui campi ereditati. L'API dei metadati restituisce solo le dichiarazioni dei membri diretti per una determinata classe e richiede che il client API effettui ulteriori chiamate per verificare la gerarchia ed enumerare i metodi ereditati. L'approccio dei servizi di reflection è basato sull'esposizione di una visualizzazione dei metadati di livello superiore, mentre con l'approccio delle API dei metadati il controllo sulla verifica delle strutture dati viene lasciato completamente al client API.

Torna all'inizio

Ambito

Per ogni momento specifico è possibile che più aree di memoria distinte contengano dei metadati, ad esempio un'area per il mapping di tutti i metadati di un modulo esistente su disco. Contemporaneamente, si potrebbero generare metadati in un'altra area da salvare successivamente come modulo in un file.

Nota
Con il termine modulo in questo caso si indica un file che contiene metadati.Si tratta in genere di un file con estensione obj, exe o dll che contiene sia metadati che codice MSIL, ma può anche essere un file che contiene solo metadati.

Ogni area separata di metadati in memoria viene indicata come ambito. Ogni ambito corrisponde a un modulo. I moduli spesso sono salvati come file su disco, ma questa non è una condizione obbligatoria. Gli strumenti di scripting ad esempio spesso generano metadati che non vengono mai salvati in modo permanente in un file.

Il termine ambito viene utilizzato perché rappresenta l'area all'interno della quale vengono definiti i token di metadati. Un token di metadati con valore N, ad esempio, identifica i dettagli su una definizione di classe all'interno di un determinato ambito, ma un token di metadati con quello stesso valore Npotrebbe corrispondere a un insieme di dettagli completamente diverso per un ambito diverso.

Per definire un ambito dei metadati in memoria, è necessario chiamare il metodo CComPtrBase::CoCreateInstance dell'interfaccia IMetaDataDispenser. Questo metodo consente di creare un nuovo ambito oppure di aprire un set esistente di strutture dei metadati da un file o da una posizione in memoria. Mediante ogni chiamata al metodo IMetaDataDispenser::DefineScope oppure al metodo IMetaDataDispenser::OpenScope, il chiamante specifica l'API da ricevere:

• L'interfaccia IMetaDataEmit consente agli strumenti di scrivere in un ambito dei metadati.

• L'interfaccia IMetaDataImport consente agli strumenti di leggere da un ambito dei metadati.

Torna all'inizio

Controllo degli errori

L'API dei metadati esegue un controllo minimo degli errori di semantica. I metodi di tali API presuppongono che gli strumenti e i servizi che generano metadati applichino le regole di sistema per gli oggetti definite nel sistema di tipi comuni e che sia superfluo ogni altro controllo effettuato dal motore dei metadati durante la fase di sviluppo.

Torna all'inizio

Argomenti correlati

Torna all'inizio