Esiste un modello di progettazione per suddividere i file in file più piccoli?

Question

Esiste un modello di progettazione per suddividere i file in file più piccoli?

#1 da (2 voti)

3

Sto sviluppando un progetto in cui devo caricare file molto grandi (fino a 50 MB). Attualmente sto caricando questi file completamente nella memoria (consecutiva). Questo ha il vantaggio di poter cambiare molto facilmente i byte in determinate posizioni, perché non conosco la struttura di tutti i byte.

Tuttavia, la mia intenzione è anche di cambiare la struttura, ad es. rimuovendo / aggiungendo 'pezzi'. Ora ho l'idea di rimuovere le parti "conosciute" da esso, memorizzarle in classi con un blocco dati contenente solo quelle parti e creare una sorta di elenco di riferimento per quei blocchi.

per esempio:.

File originale:

Intestazione
ChunkA 1
ChunkA 2
Intermedio
ChunkB 1
Piè di pagina

Il risultato sarà:

Istanza ChunkA 1 e ChunkA 2. ChunkB 1 istanza

Istanza "File" e un riferimento con offset di base + riferimento a tutti i blocchi.

Alla fine devo "ricreare" o scrivere il file originale (con modifiche).

Questa è in generale una buona idea o c'è qualche schema di progettazione che mi aiuti in questo?

c#

posta Michel Keijzers 01.09.2014 - 16:12

fonte

1 risposta

Leggi altre domande sui tag c#

Esiste un modo per definire una data coerente in una lingua di tipo dipendente? Dovrei indicare che un metodo soddisfa un'interfaccia?

score 2 · Accepted Answer

In primo luogo, sono d'accordo con il sentimento di alcuni dei commentatori di cui sopra che ciò di cui hai bisogno potrebbe semplicemente essere strutture dati sensibili. Ogni struttura dati può soddisfare un semplice contratto sia per leggere da un flusso di byte e scrivere su un flusso di byte. Per file con dimensioni di 50 MB, potrebbe essere tutto ciò di cui hai bisogno. Tenerlo in considerazione con il resto della risposta.

Tuttavia, sento che potresti provare a fare leva su concetti più profondi qui.

Il primo che viene in mente è l'efficienza con i buffer. Credo che un trucco comune qui sia quello di avere "parti" tampone preassegnate di una dimensione nota e usare liste di "parti" del buffer. In C #, l'uso di IList > viene in mente come un involucro efficiente attorno ad array preselezionalmente preallocati. Vedi qui . Si noti che queste dimensioni del buffer spesso hanno avuto affinità anche con le dimensioni del settore del disco e le dimensioni della pagina di memoria. Una definizione efficiente della struttura in avanti può consentire interessanti ottimizzazioni in seguito. Ad esempio, il formato di archivio TAR utilizza un record di intestazione 512 byte per questo tipo di motivo. Se copi un file da un TAR, i limiti del tuo settore non si incasinano, il che può essere molto bello.

In secondo luogo, mi chiedo se uno studio del progetto alla base della corda per la gestione delle stringhe potrebbe dare qualche intuizione. Segue una linea di pensiero simile. Ciò sarebbe utile in base alla tua strategia di editing.