CQRS: el lado de la consulta

Question

Muchos de los artículos de blogsphere relacionados con la separación de CQRS (repsonibilidad de la consulta del comando) parecen implicar que todas las pantallas/viewmodels son planas. p.ej. Nombre, edad, ubicación de nacimiento, etc. y por lo tanto, la sugerencia de que la implementación en cuanto a los datos los ingrese en una fuente de lectura rápida, etc. tabla única por vista mySQL, etc. y extráigalos con algo así como SqlDataReader primitivo, patee ese desagradable nhibernate ORM etc.

Sin embargo, aunque estoy de acuerdo en que los modelos de dominio no se corresponden bien con la mayoría de las pantallas, muchas de las pantallas con las que trabajo son más dimensionales, y estoy seguro de que esto es bastante común en aplicaciones LOB.

Así que mi pregunta es ¿cómo son las personas pantalla en la que por ejemplo se muestra un resumen de los datos del cliente y, a continuación una lista de sus órdenes con un enlace [más detalle] etc .... manipulación

pensaba manteniendo la consulta directa de SQL a la base de datos de Query rompiendo la combinación externa para que pueda construir un ViewModel adecuado para ver, pero parece exagerado?

Alternativamente (esto empieza a parecer asqueroso) en la tabla CustomerSummaryView tiene una columna text/big (cualquiera que sea el tipo en su base de datos) llamada Orders, y las columnas de la cuadrícula de pantalla Resumen de pedidos están separadas por, y filas por | Incluso con el tipo de datos XML todavía está sucio.

¿Alguna idea sobre una práctica óptima?

Answer 1

si alguien realmente está diciendo que sus modelos de vista deben ser planos, están simplificando demasiado su ejemplo o están hablando un montón de tonterías. los datos jerárquicos no son malos y no deben evitarse en sus viewmodels.

Realmente no hay 'mejores prácticas' para esto. todo es muy subjetivo en la forma de cargar los datos. necesita encontrar una solución que funcione bien para su equipo y sistema actual. y también debe comprender qué otras opciones existen, porque probablemente se encontrará con una situación en la que su solución actual es inadecuada.

aquí están algunas de las maneras en que manejar esto, dependiendo de la aplicación que estoy trabajando, en C#/.NET:

• conjuntos de datos ADO.NET y recta, y se unen directamente a la base de datos los controles de la pantalla ** escribir código SQL directamente a cargar el conjunto de datos ** utilizar vistas en la base de datos para cargar el conjunto de datos ** uso almacenado procs para cargar el conjunto de datos

• NHibernate y objetos DTO/viewmodel ** Normalmente uso vistas cuando voy g por esta ruta: crearé un conjunto de vistas sobre el esquema de mi dominio, que desnormalizaré los datos en el modelo que necesito y luego usaré NH para cargarlo mediante un segundo conjunto de mapas

• DTO/Automapper desde el modelo de dominio ** No me gusta este enfoque a menos que sepa que ya tengo todo lo del modelo de mi dominio cargado en la memoria. Voy a usar una herramienta como AutoMapper para transferir datos de mi modelo de dominio en un DTO/ViewModel

estoy seguro de que hay otras opciones, pero estos son los tres que yo uso más a menudo, con el fin de con qué frecuencia los uso. todos ellos tienen sus propios costos/beneficios. pero lo importante es comprender que puede y debe recuperar los datos de una manera que le facilite llenar sus pantallas.

Answer 2

Si desea trabajar con diferentes dimensiones en sus vistas, no hay problemas para hacerlo. No está diciendo que no puedes usar varios modelos de vista debajo de una vista. El desnormalizador es responsable de rellenar las vistas de la base de datos con los datos correctos. Eche un vistazo a la publicación this, explica cómo funciona el denormalizador y puede ponerlo en la dirección correcta con respecto a su pregunta.

Answer 3

Sí, hay una confusión que surge. Así es como sucede: primero, para ayudar realmente a las personas nuevas a entender de qué se trata CQRS, y para llegar a la conclusión de cómo difiere de la arquitectura en capas típica, la gente dice cosas como "tus modelos de visualización pueden ser completamente planos", y "Debería tener un modelo de tabla por vista en su base de datos de Query".

Pero eso solo tiene la intención de aclarar el punto ... no es cierto que debe tener solo una tabla por modelo de vista (aunque en la mayoría de los casos, probablemente debería). Lo que esas afirmaciones intentan decir es lo siguiente: "Debes liberarte de algunas reglas que has seguido durante mucho tiempo sobre la normalización. Con la arquitectura CQRS, tienes la oportunidad de crear tablas de bases de datos en tu canal de consultas. que están completamente formados de acuerdo a las necesidades de su vista y nada más. Asegúrese de aprovechar al máximo esto. No vaya a la mitad normalizando estas tablas solo porque es lo que está acostumbrado a hacer. En cambio, siga adelante y haga cosas que antes se consideraban impensables, como crear una tabla de base de datos por modelo de vista o hacer que las tablas de su modelo de vista fueran completamente planas ".

Todavía hay casos como el suyo donde el esquema que mejor se adaptaría a sus necesidades tendría varias tablas. Incluso podrías (Dios no lo quiera) hacer un Join o dos. Está bien, siempre que haya diseñado las tablas de la base de datos para que sirvan a su vista, y no al revés. Pero tenga cuidado, es fácil deslizarse por la pendiente de la normalización y compartir datos entre muchas vistas en la base de datos de Query. No vayas allí ... simplemente no hay razón y esto implica más costo que beneficio. El objetivo principal es este: tu lógica de visualización debería estar muerta, muerta simple. Desea que las reglas inteligentes vivan en el lado del Comando de la casa, y un poco en los Suscriptores que pueblan los datos en el canal de Consulta. Por lo tanto, el código que se lee desde la base de datos de Query y muestra datos en una pantalla debería ser completamente simple (casi tan simple como una "vista pasiva").

Actualización: copias Como aún más por la declaración de que no es "prohibido" para hacer algunas une el tiempo que usted ha diseñado la forma de base de datos para servir mejor a la tarea que se está logrando, considere OLAP. El esquema en estrella es una perfecta ejemplo de un esquema de base de datos diseñada para apoyar lee, que encaja perfectamente en el lado de consulta de CQRS, y que hace implican combinaciones. Las uniones se mantienen simples, y están en su lugar para mejorar aún más los objetivos de las tareas de lectura realizadas en la base de datos.

Answer 4

Creo que a las personas les falta el punto de CQS (o CQRS, lo mismo realmente). CQR es simplemente un patrón para decir que debe tener modelos separados para leer y escribir. Lo que ese modelo es depende completamente de sus requisitos de implementación.

Las personas que han estado hablando de esto recientemente generalmente describen arquitecturas extremadamente simples y la implementación para llevar a casa que el hecho de que la mayoría del software empresarial escrito hoy está sobrediseñado y sobrediseñado.

Answer 5

Uno de los beneficios de un enfoque CQRS ES es que puede diseñar datos de visualización realmente simples (lentos). Como resultado de la secuencia de eventos, puede dar forma a sus datos de lectura de la manera que desee. Por lo tanto, a mucha gente le gusta desnormalizar los datos para que estén optimizados para la lectura. Por supuesto que no tienes que hacerlo. Pero ¿por qué no?Piense en la frecuencia de las lecturas en un LOB típico en comparación con las escrituras.

En caso de que lo encuentre útil y le gustaría ver algunas muestras de código, he escrito una respuesta más detallada en mi blog. Puede encontrar la publicación aquí: http://danielwhittaker.me/2014/10/05/build-master-details-view-using-cqrs-event-sourcing/