Interfacce di archiviazione strutturate

I servizi di archiviazione strutturati sono organizzati in tre categorie di interfacce . Ogni set rappresenta un livello successivo di riferimento indiretto o astrazione tra un file composto, gli oggetti contenuti e i supporti fisici in cui sono archiviati questi singoli componenti.

La prima categoria di interfacce è costituita da IStorage, IStreame IRootStorage. Le prime due interfacce definiscono la modalità di archiviazione degli oggetti all'interno di un file composto. Queste interfacce forniscono metodi per l'apertura di elementi di archiviazione, il commit e il ripristino delle modifiche, la copia e lo spostamento di elementi e la lettura e la scrittura di flussi. Queste interfacce non riconoscono i formati di dati nativi dei singoli oggetti e pertanto non dispongono di metodi per salvare tali oggetti nell'archiviazione permanente. L'interfaccia IRootStorage include un singolo metodo per associare un documento composto a un nome di file system sottostante. I client devono implementare queste interfacce per i file composti.

La seconda categoria di interfacce è costituita dalle interfacceIPersist, che gli oggetti implementano per gestire i dati persistenti. Queste interfacce forniscono metodi per leggere i formati di dati di singoli oggetti e quindi sapere come archiviarli. Gli oggetti sono responsabili dell'implementazione di queste interfacce perché i client non conoscono i formati di dati nativi dei relativi oggetti annidati. Queste interfacce, tuttavia, non hanno alcuna conoscenza di supporti di archiviazione fisici specifici.

Una terza categoria è costituita da una singola interfaccia, ILockBytes, che fornisce metodi per la scrittura di file in supporti fisici specifici, ad esempio un disco rigido o un'unità nastro. Tuttavia, la maggior parte delle applicazioni non implementerà l'interfaccia ILockBytes perché COM fornisce già implementazioni per le due situazioni più comuni, ovvero l'implementazione basata su file e l'implementazione basata sulla memoria. L'oggetto di archiviazione file composto chiama i metodi ILockBytes non vengono chiamati direttamente nell'implementazione.

Limiti di implementazione di file composti

L'implementazione COM dell'architettura Structured Storage viene chiamata file composti. Gli oggetti di archiviazione, implementati nei file composti, includono un'implementazione delle interfacceIPropertyStorageE IPropertySetStorage.

I puntatori all'implementazione di file composta di queste interfacce vengono acquisiti chiamando la funzioneStgCreateStorageEx per creare un nuovo oggetto file composto oppure StgOpenStorageEx per aprire un file composto creato in precedenza.

Un metodo alternativo per l'acquisizione di un puntatore all'implementazione di file composta di queste interfacce consiste nel chiamare la funzione stgCreateDocfile o stgOpenStorage. Tutte e quattro le funzioni vengono considerate come implementazioni di file composti.

L'implementazione di file composta può essere configurata per l'uso di settori di 512 o 4096 byte, come definito nella strutturaSTGOPTIONS.

L'implementazione composta dei file composti è soggetta ai vincoli di implementazione seguenti.

Limite	File composto
Limiti delle dimensioni dei file:	512: 2 gigabyte (GB) 4096: fino ai limiti del file system
Dimensioni massime dell'heap necessarie per gli elementi aperti:	512: 4 megabyte (MB) 4096: fino ai limiti di memoria virtuale
Si apre la radice simultanea (apre lo stesso file):	Se vengono specificati STGM_READ e STGM_SHARE_DENY_WRITE, i limiti vengono definiti dai limiti del file system. In caso contrario, è previsto un limite di 20 entità radice simultanee dello stesso file.
Numero di elementi in un file:	512: Illimitato, ma le prestazioni possono peggiorare se gli elementi sono numerici nelle migliaia 4096: Illimitato

A causa del limite di dimensioni heap di 4 MB, il numero di elementi aperti in modalità transazionata è in genere limitato a diverse migliaia di elementi.