¿Cómo es la separación comando de consulta (SCC) implementó cuando se utiliza un ORM?

Question

El principio detrás del patrón arquitectónico SCC es que separe sus consultas y comandos por caminos distintos. Lo ideal sería que su tienda de persistencia se puede leer / escribir particiones, pero en mi caso, hay una sola base de datos, normalizada.

Si está utilizando un ORM (NHibernate en mi caso), está claro que el ORM se utiliza cuando la emisión de comandos. Pero ¿qué pasa con todas las diversas consultas que necesita para funcionar a dar forma a los datos (DTO) para pantallas de usuario, que es una práctica común para deshacerse de la ORM cuando se hace la parte de consulta de SCC?

¿Dónde debería poner en práctica mis consultas y proyecciones DTO? ADO.NET recta (DataReaders, DTO, DataTables, procedimientos almacenados)? Algunas consultas son únicas e implican una gran cantidad de combinaciones para tirar todo junto. No quiero desnormalizar la base de datos para las consultas, pero podría crear vistas (desnormalización del hombre pobre).

Answer 1

Estoy asumiendo por CQS quiere decir el patrón arquitectónico DDD alias CQRS , no es estrictamente el CQS principio.

Todavía haría uso de NHibernate para su único modelo de leer. Hay muchas ventajas, como futuros y de múltiples consultas, la carga diferida / ansiosos etc ... que optimizarán chattiness DB. Además, será más fácil para componer consultas con un ORM si la interfaz de usuario permite al usuario cambiar esencialmente la cláusula where.

En cuanto a cómo manejar técnicamente un único modelo de leer, puede marcar un inmutable con NHibernate. Usted simplemente puede marcar todas las entidades del modelo de lectura inmutable. Además, no creo que se pueda actualizar las proyecciones en NHibernate por lo que es otra opción para ir como su modelo de sólo lectura (Alguien por favor me corrija si estoy equivocado ya que no soy 100% seguro).

En cuanto a las asignaciones de NH feas o imposibles: NH puede asignar a las vistas y procedimientos almacenados, por lo que creo que estaría bien utilizar estos cuando es necesario. Las vistas son probablemente un poco más flexible que los procedimientos almacenados para un único escenario leer porque su SQL seguirá siendo dinámico. Sin embargo, si usted necesita leer / escribir para cualquiera de estas estructuras aplanadas me asigna a un proceso de almacenamiento.

Answer 2

En última instancia, la idea es que usted debe usar lo hace el canal de consulta más fácil para usted para construir y mantener. Ya no tiene que preocuparse acerca de las actualizaciones, la aplicación de reglas de negocio, mantener la integridad de los datos, o incluso Manejo de carga (en su mayor parte). Así que usted es libre de elegir muchas opciones que antes no estaban sobre la mesa.

Pero NHibernate todavía puede ser una buena opción ... es simplemente ya no es el predeterminado automática (que a veces es por el lado de comandos).

Hemos optado por utilizar Castillo Active Record (que se basa en NHibernate bajo el capó), principalmente porque tiene una buena característica que va a generar una mesa para que de una clase. Esto se ajusta de manera excelente para nosotros, porque aquí está nuestro flujo de trabajo: En primer lugar, creamos una clase modelo de vista. Esta clase está totalmente dominado por las necesidades de la vista. A continuación, marcamos que ViewModel con el castillo de atributos de Active Record. Entonces, nos preguntamos Active Record para generar la tabla correspondiente para esa clase en la base de datos de consulta. Esta es la manera más rápida, más suave que hemos encontrado para conseguir rápidamente una tabla de base de datos de consulta que sirve a la clase ViewModel. La generación automática refleja la realidad de que la única razón de ser de la tabla es servir a la vista.

Answer 3

Estamos utilizando EF para la parte de comandos y rectas ADO.NET => DTO para la cadena de consulta. Ventajas:

1) Capacidad para optimizar las consultas SQL y utilizar tienda de avanzada DB funciones que no se abstrae en la capa ORM

2) Menos sobrecarga

Sin embargo, estamos utilizando la separación sólo para piezas exigentes (búsqueda), el resto se basa en el modelo común de Entity Framework.

Answer 4

No hay necesidad de utilizar un enfoque diferente a la lectura de su base de datos frente a la actualización de su base de datos. CQS simplemente que ordena que la actualización del almacén de datos debe estar separado de las consultas que leer el estado del almacén de datos.

Puede seguir utilizando NHibernate para leer desde el almacén de datos, pero es posible que desee hacer evidente mediante la creación de dos clases diferentes para encapsular el acceso a los datos. Una clase tendría métodos para leer (consulta) el almacén de datos, la otra clase tendría métodos para la emisión de órdenes (añadir, actualizar, eliminar) al almacén de datos.

Lo que estamos tratando de evitar es un método que consigue un mensaje de la base de datos, y luego marca el mensaje como leído en la base de datos. Esta debe ser de dos llamadas a métodos distintos. No debe cambiar el estado y devolver un valor desde el mismo método.

Answer 5

Me gusta mantener de ORM separado para lee y escribe lo que me gustaría utilizar (y uso):

Nhibernate para los comandos - muy bien los mapas de mi modelo de dominio

Dapper.net para consultas - muy bien los mapas de mi DTO y permite felxibility si la consulta es demasiado compleja

.

Son una pareja perfecta al igual que Han Solo y Chewbacca.