nhibernate - hibernate java netbeans mysql

¿Cómo se implementa la Separación de consultas de comando(CQS) cuando se usa un ORM?

Question

El principio detrás del patrón arquitectónico de CQS es que usted separa sus consultas y comandos en rutas distintas. Idealmente, su almacén de persistencia puede estar particionado de lectura / escritura, pero en mi caso, hay una base de datos única y normalizada.

Si está utilizando un ORM (NHibernate en mi caso), está claro que el ORM se utiliza al emitir comandos. Pero ¿qué pasa con todas las diversas consultas que necesita ejecutar para dar forma a los datos (DTO) para las pantallas de usuario? ¿Es una práctica común deshacerse del ORM al hacer el lado de Consulta de CQS?

¿Dónde debo implementar mis consultas y proyecciones DTO? ¿ADO.NET directo (datareaders, dtos, datatables, procs almacenados)? Algunas consultas son bastante únicas e involucran muchas uniones para juntar todo. No quiero desnormalizar la base de datos para las consultas, pero podría crear vistas (desnormalización del hombre pobre).

Answer 1

En última instancia, la idea es que debe usar lo que hace que el canal de consulta sea más fácil de construir y mantener. Ya no tiene que preocuparse por las actualizaciones, hacer cumplir las reglas comerciales, mantener la integridad de los datos o incluso manejar la carga (en su mayor parte). Así que puedes elegir muchas opciones que antes no estaban en la mesa.

Pero NHibernate todavía puede ser una buena opción ... ya no es el valor predeterminado automático (que a veces es para el lado del Comando).

Hemos elegido usar Castle Active Record (que se basa en NHibernate debajo del capó), principalmente porque tiene una buena característica que generará una tabla para usted de una clase. Esto encaja perfectamente para nosotros, porque aquí está nuestro flujo de trabajo: Primero, creamos una clase ViewModel. Esta clase está formada enteramente para las necesidades de la Vista. Luego, marcamos ese ViewModel con los atributos de Castle Active Record. Luego, le pedimos a Active Record que genere la tabla correspondiente para esa clase en la base de datos de consultas. Esta es la forma más rápida y fluida que hemos encontrado para obtener rápidamente una tabla de base de datos de consultas que sirve a la clase ViewModel. La generación automática refleja la realidad de que la única razón por la que existe la tabla es para servir a la vista.

Answer 2

Estamos utilizando EF para la parte del comando, y ADO.NET directo>> DTO para la cadena de consulta. Ventajas:

1) Capacidad para optimizar las consultas de SQL y utilizar funciones avanzadas de almacenamiento de base de datos no resumidas en la capa ORM

2) Menos gastos generales

Pero estamos usando la separación solo para partes exigentes (búsqueda), el resto se basa en el modelo de Entity Framework común.

Answer 3

Me gusta mantener los ORM separados para las lecturas y escrituras, por lo que usaría (y uso):

Nhibernate para comandos - mapea bellamente mi modelo de dominio

Dapper.net para consultas: mapea maravillosamente mis DTO y permite la flexibilidad si la consulta es demasiado compleja.

Son una pareja perfecta como Han Solo y Chewbacca.

Answer 4

No es necesario utilizar un enfoque diferente para leer su base de datos en lugar de actualizar su base de datos. CQS simplemente establece que los comandos que actualizan el almacén de datos deben estar separados de las consultas que leen el estado del almacén de datos.

Aún puedes usar NHibernate para leer desde tu almacén de datos, pero es posible que desees hacerlo mediante la creación de dos clases diferentes para encapsular el acceso a tus datos. Una clase tendría métodos para leer (consultar) el almacén de datos, la otra clase tendría métodos para emitir comandos (agregar, actualizar, eliminar) al almacén de datos.

Lo que intenta evitar es un método que recibe un mensaje de la base de datos y luego lo marca como leído en la base de datos. Esto debería ser dos llamadas de métodos distintos. No debe cambiar el estado y devolver un valor del mismo método.

Answer 5

Supongo que por CQS te refieres al patrón arquitectónico DDD, también CQRS como CQRS , no es estrictamente el principio tradicional de CQS .

Todavía usaría NHibernate para su modelo de solo lectura. Hay muchas ventajas, como consultas futuras y múltiples, carga perezosa / ansiosa, etc ... que optimizarán la capacidad de DB. Además, será más fácil redactar consultas con un ORM si la IU permite que el usuario cambie esencialmente la cláusula where.

Con respecto a cómo manejar técnicamente un modelo de solo lectura, puede marcar una entidad immutable con NHibernate. Simplemente puede marcar todas las entidades de su modelo de lectura como inmutables. Además, no creo que pueda actualizar las proyecciones en NHibernate, así que esa es otra opción a seguir como su modelo de solo lectura (Alguien, por favor, corríjame si me equivoco, ya que no estoy 100% seguro).

Con respecto a los mapas de NH feos o imposibles: NH puede mapear vistas y procedimientos almacenados, por lo que creo que estaría bien usarlos cuando lo necesite. Las vistas son probablemente un poco más flexibles que los procedimientos almacenados para un escenario de solo lectura porque su SQL aún será dinámico. Sin embargo, si necesita leer / escribir para cualquiera de estas estructuras aplanadas, asignaría a un procedimiento de almacenamiento.