CQRS: quanto dovrebbero essere granulari le domande?

Question

CQRS: quanto dovrebbero essere granulari le domande?

#1 da (1 voti)

3

Ho un sistema che usa CQRS con le Query scritte usando Dapper. Ha funzionato bene, tranne che c'è stata una proliferazione di classi di query che fanno quasi la stessa cosa. Lo svantaggio di questo è che le query aggiuntive significano un sovraccarico di manutenzione aggiuntivo (soprattutto a causa delle stringhe SQL) e altri problemi associati all'utilizzo di molte piccole classi, ma il lato positivo è che le classi sono conformi al Principio di Responsabilità Unica e sono in qualche modo più facili da ragionare circa.

Se stavo usando stored procs, probabilmente creerei solo alcune query più grandi, di uso generale (al fine di simulare il sovraccarico del mantenimento dell'SQL), ma il contrario sembra essere il caso in questa implementazione.

Qual è l'approccio migliore in termini di dimensioni della query? Dovrebbe esserci una query per viewmodel, o le query dovrebbero essere scomposte?

sql single-responsibility mvvm cqrs dapper

posta NMrt 01.11.2016 - 03:04

fonte

1 risposta

Leggi altre domande sui tag sql single-responsibility mvvm cqrs dapper

Perché utilizzare un iteratore / generatore per implementazioni di valutazione lazy? Come recuperare le licenze di libreria di terze parti

score 1 · Answer 1

It's worked out well, except that there has been a proliferation of query classes that do almost the same thing.

In base alla mia comprensione, ciò sembra sospetto. Non necessariamente sbagliato, ma mi darebbe un pizzico di leggere attentamente i record di decisione dell'architettura capire se i miei predecessori e colleghi seguivano la loro comprensione del dogma o paragonassero gli scambi commerciali con una serie specifica di priorità che li metteva in tale direzione.

If I was using stored procs, I'd probably just create a few bigger, general purpose queries (in order to mimimize the overhead of maintaining the SQL)

Anche a me sembra un approccio abbastanza ragionevole. "Non ne avrai bisogno", e tutto il resto.

What's the best approach in terms of query size? Should there be a query per viewmodel, or should the queries be decomposed?

La mia comprensione è che il modello letto dovrebbe essere piuttosto sottile; stiamo supportando un'API e, se l'abbiamo fatto bene, dovrebbe essere stabile . La vera meccanica della lettura dei dati dall'archivio di persistenza dovrebbe dare la priorità alla semplicità o alla (minima) latenza, a seconda del valore del business.

In particolare, quando si identifica una query specifica nell'API che richiede particolare attenzione (deve soddisfare uno SLA particolarmente rigido), dovrebbe essere banale rifattorizzare l'implementazione nel proprio percorso di codice (che è possibile quindi avviare ottimizzazione).

Il mio suggerimento sarebbe quello di rivedere CQRS - ma diverso , di Udi Dahan (parlare) (diapositive) . In questo caso, sto pensando al suo punto: se fare una modifica richiede di ripetere te stesso in un livello dopo l'altro, allora qualcosa è andato di lato.