Dividere la classe di accesso ai dati in lettore e scrittore o combinarli?

StackOverflow https://stackoverflow.com/questions/29558

  •  09-06-2019
  •  | 
  •  

Domanda

Questo potrebbe essere un aspetto "discussivo", ma mi piacerebbe davvero sentire il tuo punto di vista al riguardo.

In precedenza ho spesso scritto classi di accesso ai dati che gestivano sia la lettura che la scrittura, il che spesso portava a una denominazione inadeguata, come FooIoHandler ecc.La regola pratica secondo cui le classi difficili da nominare probabilmente sono mal progettate suggerisce che questa non è una buona soluzione.

Quindi, di recente ho iniziato a dividere l'accesso ai dati in FooWriter e FooReader, il che porta a nomi più carini e offre una certa flessibilità aggiuntiva, ma allo stesso tempo mi piace tenerli insieme, se le classi non sono troppo grandi.

La separazione lettore/scrittore è un progetto migliore o dovrei combinarli?Se dovessi combinarli, che diavolo dovrei chiamare la classe?

Grazie /Erik

È stato utile?

Soluzione

ORM potrebbe essere la soluzione migliore.
Oppure utilizzare un modello di tipo repository, con un oggetto "thingContext" responsabile della persistenza dello stato.

Personalmente, utilizzo il pattern activeRecord, in cui la logica di salvataggio è integrata in una classe base, ma lo lascio a favore di un pattern di repository in stile nHibernate.L'indennità per DDD e testare cose senza db è molto utile da avere in una situazione di tipo framework, in cui la mia logica aziendale sta ora guadagnando terreno per una nuova interfaccia utente.

Altri suggerimenti

Ora sto usando Linq to Sql.Questo risolve completamente il problema.

Tuttavia, se non disponi di questa opzione (o di uno strumento ORM simile), non vedo alcun motivo per separare i metodi di lettura/scrittura.Aggiunge semplicemente più classi e complica l'accesso ai dati.L'ho sempre progettato così:

  1. Componente/oggetto aziendale:Auto
  2. Accesso ai dati, contenente metodi statici di lettura e scrittura:CartaDB

Esempio di utilizzo:

Car car = new Car();
car.Manufacturer = "Toyota"
car.Model = "Camry"
car.Year = 2006;
car.CarID = CarDB.InsertCar(car)
car.OwnerID = 2;
CarDB.UpdateCar(car);

Ciò ha senso anche per l'accesso ai dati in cui è necessario eseguire sia la lettura che la scrittura come parte della stessa transazione.Se dividessimo le classi, dove andrebbe a finire?

Ignorando l'ORM (non perché sono a favore o contro) li terrei nella stessa classe.Sono entrambi aspetti di un'unica responsabilità e separarli ti fa semplicemente guardare in due posti in cui non riesco davvero a pensare a una buona ragione per cui vorresti farlo.

Qualcosa che legge e scrive su un archivio backend potrebbe essere chiamato accesso dati, ReaderWriter, IO o Store.

Allora che ne dici di uno di:

  • FoodDataAccessor
  • FooAccessor
  • FooReaderWriter
  • FooRW
  • FooIO
  • FooStore
  • FooStorage

Quando posso scegliere, generalmente sottoclasso il lettore per creare lo scrittore.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top