Modelli di sviluppo per gestire l'importazione / esportazione dei dati

Question

Modelli di sviluppo per gestire l'importazione / esportazione dei dati

#1 da (2 voti)
#2 da (0 voti)

5

Ho un'applicazione web ASP.NET che consente all'utente finale di esportare i dati in un formato di file flat. (essenzialmente prendendo un backup point-in-time del proprio lavoro)

In un secondo momento possono ricaricare (importare) quei dati nuovamente nell'applicazione web.

Il formato effettivo del backup è piuttosto banale. Un oggetto grafico viene serializzato usando WCF DataContractSerializer su xml, e quindi il documento xml risultante viene compresso. L'importazione, decomprimila e deserializza i dati.

C'è un piccolo problema che vedo con questo approccio. versioning ... man mano che il tempo passa e le strutture dei dati cambiano (le proprietà / i child-collections vengono aggiunti / rimossi o rinominati) le versioni precedentemente esportate dei dati di un utente non verranno più mappate al grafo degli oggetti nell'applicazione.

Esistono modelli specifici o pratiche che risolvono questo problema? o qualsiasi altro materiale di lettura che potresti raccomandare.

design-patterns asp.net import serialization export

posta Eoin Campbell 17.04.2012 - 15:34

fonte

2 risposte

0

Hai preso in considerazione l'aggiunta di una versione all'esportazione e quindi il confronto delle versioni durante l'importazione?

Se le versioni non corrispondono, puoi non riuscire a importare o avvisare l'utente che è probabile che l'importazione abbia esito negativo. Non vedo nessun altro modo ragionevole per risolvere questo problema.

risposta data 22.04.2012 - 17:26

fonte

Leggi altre domande sui tag design-patterns asp.net import serialization export

Pro e contro della serializzazione intrusiva e non intrusiva? Qual è una buona strategia per legare oggetti vista a modelli di oggetti in C ++?

score 2 · Accepted Answer

Abbiamo utilizzato .NET Xml per la serializzazione di un grafico piuttosto grande di oggetti .NET per diversi anni. Abbiamo optato per un approccio molto semplice: mantenere gli oggetti compatibili all'indietro a livello di codice. Generalmente aggiungiamo solo nuove proprietà e, nel caso in cui abbiamo modificato il tipo di dati di una proprietà, abbiamo creato una nuova proprietà con il tipo di dati modificato e inizializzata dai vecchi dati quando l'utente ha aggiornato.

Penso che l'unica best practice che abbiamo istituito sia che ogni nuova proprietà sia sempre stata aggiunta come proprietà a pieno titolo e non solo come variabile membro della classe. Questo ci ha permesso di garantire che il codice inizializzasse sempre la nuova proprietà su un valore predefinito utile (invece del valore vuoto / nullo a cui è inizializzato durante la deserializzazione).

Questo ci ha coperto per gli aggiornamenti all'applicazione per oltre 5 anni, senza errori causati dalla deserializzazione delle vecchie versioni degli oggetti nella versione più recente dell'applicazione. (una volta adottato l'approccio sopra).