Architettura di serializzazione dei dati, iniezione su costruzione e chiamata su chiamata

Question

Architettura di serializzazione dei dati, iniezione su costruzione e chiamata su chiamata

#1 da (1 voti)

2

Sto creando un meccanismo di serializzazione / deserializzazione dei dati essenzialmente per un oggetto di archiviazione persistente. A causa della varietà di sistemi su cui questo meccanismo può essere eseguito, ci deve essere un numero variabile di "driver" che potrebbero essere utilizzati per serializzare o deserializzare i dati.

Ho difficoltà a capire il livello appropriato di astrazione per questo sistema. In primo luogo, quando costruisco un "driver", dovrebbe avere un riferimento all'oggetto che sto memorizzando, o questo oggetto deve essere passato alle varie funzioni di scrittura?

Quindi, supponiamo di avere un po 'di DataAccessLayer che avvolge il mio DataAccessDriver . Il mio DataAccessLayer contiene necessariamente un riferimento a qualche DataObject che avvolge e utilizza DataAccessDriver per mantenere effettivamente una rappresentazione serializzata di DataObject .

La domanda è, se la DataAccessDriver è costruita con un riferimento al DataObject , o dovrei passare in DataObject per ogni chiamata di funzione che DataAccessDriver fa?

dependency-injection architecture construction serialization

posta MirroredFate 20.09.2014 - 00:16

fonte

1 risposta

Leggi altre domande sui tag dependency-injection architecture construction serialization

Modello dati per query persistenti nel database Quale modello di progettazione per una singola classe che accede a un oggetto che rappresenta una struttura dati?

score 1 · Answer 1

o, let's say I have an some DataAccessLayer which wraps my DataAccessDriver.

Dubito molto che ci dovrebbe essere una dipendenza così strong. Io voto per il sottosistema di serializzazione per essere completamente indipendente da altre cose nella vostra applicazione. Nota: voto per la serializzazione per essere indipendente dal livello di persistenza. Serializzare un oggetto è una responsabilità, salvarlo ovunque è un altro.

My DataAccessLayer necessarily contains a reference to some DataObject which it also wraps, and it uses the DataAccessDriver to actually keep some serialized representation of the DataObject.

Che intendi con "avvolge"? Ha creato qualche istanza di DataObject, lo prendo. E poi usa la serializzazione per serializzarlo.

The question is, should the DataAccessDriver be constructed with a reference to the DataObject, or should I pass in the DataObject for every function call the DataAccessDriver makes?

Penso che ciò dipenda da quanta necessità di serializzazione della configurazione. Se per la serializzazione è necessario eseguire alcune impostazioni complesse del serializzatore a parte il semplice riferimento agli oggetti che passano, allora probabilmente sarebbe meglio passare l'oggetto al costruttore del serializzatore, impostare vari valori predefiniti del costruttore e quindi chiamare solo serialize() . Se la logica di serializzazione è semplice come passare un riferimento a un oggetto, voterò per un metodo nel serializzatore che accetta l'istanza dell'oggetto come argomento. Questo caso è anche leggermente migliore in termini di prestazioni perché non è necessario creare una nuova istanza di serializer ogni volta che si serializza un altro oggetto.