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 vengono archiviati questi singoli componenti.
La prima categoria di interfacce è costituita da IStorage, IStream e 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 ha un unico metodo per associare un documento composto a un nome del file system sottostante. I client devono implementare queste interfacce per i file composti.
La seconda categoria di interfacce è costituita dalle interfacce IPersist , che gli oggetti implementano per gestire i dati persistenti. Queste interfacce forniscono metodi per leggere i formati di dati dei 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 degli 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 che non vengono chiamati direttamente nell'implementazione.
Limiti di implementazione di file composti
L'implementazione COM dell'architettura di archiviazione strutturata è denominata file composti. Gli oggetti di archiviazione, come implementato nei file composti, includono un'implementazione delle interfacce IPropertyStorage e IPropertySetStorage .
I puntatori all'implementazione di file composta di queste interfacce vengono acquisiti chiamando la funzione StgCreateStorageEx per creare un nuovo oggetto file composto o 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 precedente e più limitata. Tutte e quattro le funzioni vengono considerate come implementazioni di file composti.
L'implementazione di file composta può essere configurata per l'utilizzo di settori di 512 o 4096 byte, come definito nella struttura STGOPTIONS .
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 sono definiti dai limiti del file system. In caso contrario, è previsto un limite di 20 apertura radice simultanea 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.