Separazione delle responsabilità di lettura / scrittura di un DB

Question

Separazione delle responsabilità di lettura / scrittura di un DB

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

3

Stiamo lavorando su un sistema di reporting che ha una chiara scrittura e un percorso di lettura. Ad esempio, le scritture si verificano solo dopo aver consumato eventi da una coda e le letture si verificano solo quando vengono pubblicate richieste da un'API. Probabilmente le responsabilità non si mescoleranno, vale a dire che la scrittura del servizio nel DB non utilizzerà le query utilizzate dall'API e viceversa.

Il codice è molto lungo (causa java) e potrebbe essere fonte di confusione per una nuova persona. Stavo pensando di separare il DB in due classi, ReportingIngestDBClient vs ReportingReadDBClient non sposato con i nomi.

Mi stavo chiedendo:

1) Qualcuno ha seguito questo schema? Ha reso le cose più o meno chiare? Se sì, quali nomi hai usato?
2) Se non hai seguito lo schema di creazione di 2 oggetti separati per gestire query diverse, hai un'opinione strong contro di esso e perché?

programming-practices java object-oriented-design

posta devkaoru 28.09.2017 - 16:45

fonte

2 risposte

Leggi altre domande sui tag programming-practices java object-oriented-design

Utilizzare più dispatch dinamico potrebbe ridurre i tempi di compilazione? Che modelli ho? E cos'è un livello?

score 1 · Answer 1

Come ha detto Laiv nel suo commento, dovresti esaminare il modello di progettazione di CQRS. E fammi espandere qui.

CQRS è l'acronimo di Segregazione della responsabilità della query di comando. L'idea fondamentale è dividere il tuo codice di accesso ai dati in due categorie nettamente separate:

Query : restituisce un risultato e non modifica lo stato osservabile del sistema (sono privi di effetti collaterali).

Comandi : cambia lo stato di un sistema ma non restituisce un valore.

Ecco alcuni articoli per iniziare sul modello di progettazione CQRS:

Martin Fowler - CQRS
Greg Young - CQRS, UI basate sulle attività, Evento Sourcing agh!
Udi Dahan - Chiarito CQRS

score 0 · Answer 2

Ogni volta che aggiungi una struttura riduci anche la flessibilità, quindi in generale dovresti avere tutta la struttura di cui hai veramente bisogno. Direi che questa separazione non è veramente necessaria, e una maggiore flessibilità sarebbe meglio.

Anch'io lo guarderei da questa prospettiva. Uno degli scopi dell'incapsulamento è semplificare il codice isolando la conoscenza (business logic) in una parte del sistema. Se si dispone di database di lettura e scrittura separati, è necessario ridurre al minimo il numero di posizioni nel software che è necessario conoscere.

Sembra naturale che il doppio design del database sia compreso dal livello di accesso ai dati, ma se dividi l'accesso ai dati in due classi allora molte altre parti del tuo sistema devono essere consapevoli di questo design, perché decidere quale dei due livelli di dati dovrebbero chiamare in base al fatto che il database venga aggiornato o meno. Per il resto dell'applicazione sapere se il database viene aggiornato significa avere una conoscenza dettagliata di come funziona il database, che è una sorta di accoppiamento.

In sintesi, se crei due classi, i consumatori di queste classi devono comprendere abbastanza sulla progettazione del database per fare la scelta corretta su quale utilizzare, e questo crea un accoppiamento tra la progettazione del database e i consumatori del livello dati . Il livello dati dovrebbe nascondere questi dettagli a questi consumatori.