CQRS - Il lato query

Question

Molti degli articoli di blogsphere relativi alla separazione di CQRS (command query repsonsibility) sembrano implicare che tutte le schermate/viewmodels siano piatte. per esempio. Nome, Età, Luogo di nascita ecc. E quindi il suggerimento che l'implementazione è saggio li inseriamo in sorgenti di lettura veloce ecc. Una sola tabella per vista mySQL ecc. E li estrae con qualcosa come SqlDataReader primitivo, calcia quel brutto NEGNO ORM ecc.

Tuttavia, mentre sono d'accordo sul fatto che i modelli di domini non sono mappati bene alla maggior parte degli schermi, molte delle schermate con cui lavoro sono più dimensionali, e sono sicuro che questo è piuttosto comune nelle applicazioni LOB.

Quindi la mia domanda è come sono persone schermata in cui, ad esempio, viene visualizzato un riepilogo dei dati dei clienti e poi un elenco dei loro ordini con un link [maggiori dettagli] ecc .... movimentazione

ho pensato mantenendo la query SQL diretta al database delle query interrompendo il join esterno, quindi è possibile creare un ViewModel adatto per View ma sembra eccessivo?

In alternativa (questo sta iniziando a sentire sfinimento) nella tabella CustomerSummaryView ha una colonna text/big (qualunque sia il tipo nel DB) chiamata Orders, e le colonne per la griglia di riepilogo dell'ordine sono separate da, e righe per |. Anche con il tipo di dati XML è ancora sporco.

Qualche idea su una pratica ottimale?

Answer 1

se qualcuno sta effettivamente dicendo che i tuoi modellini visivi dovrebbero essere piatti, o semplificano eccessivamente il loro esempio o parlano di sciocchezze. i dati gerarchici non sono male e non dovrebbero essere evitati nei tuoi modelli di vista.

non ci sono davvero "buone pratiche" per questo, però. è tutto molto soggettivo nel modo in cui carichi i dati. hai bisogno di trovare una soluzione che funzioni bene per il tuo attuale team e sistema. e dovresti anche capire quali altre opzioni ci sono, perché probabilmente ti imbatterai in una situazione in cui la tua attuale soluzione è inadeguata.

qui sono alcuni dei modi che gestire questa situazione, a seconda dell'applicazione cui sto lavorando, in C#/.NET:

• serie di dati e ADO.NET dritto, e si legano il set di dati direttamente a i controlli della schermata ** scrivere codice SQL dritto per caricare il set di dati ** utilizzare viste nel database per caricare il set di dati ** utilizzare stored procs per caricare il set di dati

• NHibernate e oggetti DTO/ViewModel ** di solito uso le viste quando goin g giù questa rotta - Creerò una suite di viste sullo schema del mio dominio, denormalizzando i dati nel modello di cui ho bisogno e quindi utilizzando NH per caricarlo tramite una seconda serie di mappe

• DTO/Automapper dal modello di dominio ** Non mi piace questo approccio a meno che non sappia che ho già tutto in memoria dal mio modello di dominio. userò uno strumento come Automapper per trasferire i dati dal mio modello di dominio in un DTO/ViewModel

Sono sicuro che ci sono altre opzioni, ma questi sono i tre che io uso il più delle volte, al fine di quanto spesso li uso hanno tutti i loro costi/benefici. ma la cosa importante da capire è che puoi e devi recuperare i dati in un modo che faciliti la compilazione dei tuoi schermi.

Answer 2

Se si desidera lavorare con dimensioni diverse nelle viste, non ci sono problemi per farlo. C'è da dire che non puoi usare più modelli di vista sotto una vista. Il denormalizzatore è responsabile per popolare le visualizzazioni del database con i dati corretti. Dai un'occhiata al post this, spiega come funziona il denormalizzatore e potresti metterti nella giusta direzione riguardo alla tua domanda.

Answer 3

Sì, c'è una confusione che sorge. Ecco come accade: in primo luogo, al fine di aiutare davvero le nuove persone a capire che cos'è CQRS e a fare davvero da guida su come si differenzia dalla tipica architettura a più livelli, le persone dicono cose come: "I tuoi modelli di visualizzazione possono essere completamente piatti", e "Dovresti avere una tabella per modello di vista nel tuo database Query."

Ma questo è davvero solo lo scopo di guidare il punto a casa ... non è vero che tu devi avere solo una tabella per modello di vista (anche se nella maggior parte dei casi probabilmente dovresti). Ciò che queste affermazioni stanno cercando di dire è questo: "Devi liberarti di alcune regole che hai seguito per tanto tempo sulla normalizzazione. Con l'architettura CQRS, hai l'opportunità di creare tabelle di database nel tuo canale Query che sono completamente modellati in base alle esigenze del tuo punto di vista e nient'altro. Assicurati di trarne il massimo vantaggio. Non andare a metà strada normalizzando queste tabelle solo perché è ciò che sei abituato a fare. cose che prima erano considerate impensabili, come creare una tabella di database per modello di vista o rendere completamente piatte le tabelle del modello di visualizzazione. "

Non ci sono ancora casi come il vostro dove lo schema che sarebbe servito al meglio le vostre esigenze avrebbe più tabelle. Potresti anche (Dio non voglia) fare un Join o due. Va bene, a patto che tu abbia davvero progettato le tabelle del database per servire la tua vista, e non viceversa. Ma attenzione, è facile scivolare la pendenza della normalizzazione e condividere i dati tra molte viste nel database Query. Non andare lì ... semplicemente non c'è motivo e comporta più costi che benefici. L'obiettivo principale è questo: la logica della tua vista dovrebbe essere morta, semplicemente semplice. Vuoi le regole intelligenti che vivono sul lato Comando della casa e un po 'negli Abbonati che popolano i dati nel canale Query. Quindi il codice che legge dal database Query e mostra i dati su uno schermo dovrebbe essere semplicemente semplice (quasi come una "vista passiva").

Aggiornamento: Come ulteriore sostegno per l'istruzione che non è "proibito" per fare un po 'si unisce tutto il tempo che avete progettato la forma di database per servire al meglio l'attività che si sta ottenendo, in considerazione OLAP. Lo schema a stella è un perfetto esempio di uno schema di database progettato per supportare legge, che si inserisce perfettamente nella parte di query di CQRS , e che fa coinvolgere unisce. I join vengono mantenuti semplici e sono pronti per migliorare ulteriormente gli obiettivi delle attività di lettura eseguite sul database.

Answer 4

Penso che alla gente manchi il punto di CQS (o CQRS, la stessa cosa in realtà). CQR è semplicemente uno schema per dire che dovresti avere modelli separati per leggere e scrivere. Ciò che tali modelli sono è completamente all'altezza dei requisiti di implementazione.

persone che parlato di recente su questo di solito descrivere architetture estremamente semplice e implementazione di guidare a casa che il fatto che la maggior parte del software aziendale scritto oggi è over-progettato e sovra-ingegnerizzato.

Answer 5

Uno dei vantaggi di un approccio CQRS ES è la possibilità di elaborare dati di visualizzazione davvero semplici (leggi veloci). Come risultato del flusso di eventi è possibile modellare i dati del lato di lettura nel modo desiderato. Quindi a molte persone piace de-normalizzare i dati in modo che siano ottimizzati per la lettura. Ovviamente non devi. Ma perché non dovresti?Pensa alla frequenza delle letture in un LOB tipico rispetto alle scritture.

Solo nel caso a trovarlo utile e volete vedere alcuni esempi di codice che ho scritto una risposta più dettagliata sul mio blog. Potete trovare il post qui: http://danielwhittaker.me/2014/10/05/build-master-details-view-using-cqrs-event-sourcing/