¿Cuáles son los posibles problemas con la mezcla de Fluiber NHibernate y Dapper-dot-net?

.net dapper fluent-nhibernate

Pregunta

He tenido que apoyar un proyecto que usa Fluent NHibernate durante algunos años y estoy sinceramente cansado de ello. Quiero usar Dapper-dot-net ( https://github.com/StackExchange/dapper-dot-net ) en el futuro, pero algunos miembros de mi equipo están en contra de usarlo debido a la preocupación de mezclar dos marcos ORM en un proyecto.

¿Sus preocupaciones están justificadas? ¿Alguien tiene experiencia en esta área que podría enumerar por qué NHibernate y Dapper (u otras estructuras ORM) no pueden existir juntas en el mismo proyecto?

Gracias,

Respuesta aceptada

En primer lugar, no tengo experiencia directa de combinar Fluent NHibernate (FNH) y Dapper en el mismo proyecto, así que tenlo en cuenta. Sin embargo, he usado FNH, Entity Framework y Dapper de forma independiente en proyectos separados y, habiendo elegido a Dapper para el último proyecto precisamente por su simplicidad y porque quería evitar un ORM más pesado, personalmente puedo ver el atractivo de Dapper sobre más características alternativas ricas Aunque no hay ninguna razón por la cual los dos no puedan existir en el mismo proyecto per se , creo que su equipo está perfectamente justificado al plantear objeciones sobre la introducción de otra tecnología de acceso a datos en el mismo proyecto (sin embargo, si estas preocupaciones superan las ventajas de para Dapper depende, por supuesto, de los requisitos particulares de su equipo).

Algunas consideraciones / preocupaciones técnicas inmediatas que me vienen a la mente:

  • Cambio de contexto mental entre un ORM con todas las características y un envoltorio delgado alrededor de ADO.NET. Aunque en casos triviales reemplazando:

    Query (a => a.Id == id && a.Active == true) ...

    con

    "WHERE id = @Id AND active = true" ...

    no va a ser un gran salto mental, puedo entender que al depurar, cambiar entre una consulta que utiliza FNH a otra que usa SQL sin procesar y viceversa probablemente no sea la experiencia más agradable para su equipo, especialmente con más consultas complejas.

  • ¿Planea volver / consumir el mismo conjunto de entidades de dominio con sus consultas Dapper como en la actualidad? De ser así, ¿habrá problemas si necesita replicar funcionalidades como la carga diferida (que puede estar usando actualmente pero que no se proporcionará en Dapper) y las relaciones entre entidades?

  • Dapper obviamente requerirá que escriba a mano sus consultas SQL. Si se eligió FNH porque su equipo prefiere activamente escribir consultas de estilo LINQ sobre SQL sin procesar o, lo que es más importante, porque no están familiarizados con SQL, la introducción de Dapper también impondrá a su equipo la curva de aprendizaje de SQL.

  • Dapper no proporcionará tiempo de compilación para verificar sus consultas, por lo que no se marcarán los cambios en sus entidades que normalmente se recogerían en las asignaciones y consultas con fluidez, con las que su equipo pueda sentirse cómodo y en los que confíe.

Una preocupación más general sería cómo planea lidiar con una combinación de los dos a más largo plazo. No estoy familiarizado con su proyecto en particular y la cantidad de funcionalidad FNH que ha empleado, por lo que puede ser discutible, sin embargo, si planea utilizar Dapper solo en adelante, dejando su base de código existente tal como está, presumiblemente necesitará retener a alguien que tenga experiencia usando FNH si las consultas complejas que hacen un uso intensivo de la funcionalidad FNH alguna vez necesitan ser fuertemente refactorizadas o depuradas.


Respuesta popular

Solo para aclarar: creo que lo que estás preguntando es usar nHibernate y Dapper juntos en el mismo proyecto. (Fluent nHibernate no es ORM, es una biblioteca que ayuda con el mapeo).

He estado usando nHibernate + FNH durante años y en mis dos últimos proyectos web introduje Dapper.net porque estaba buscando una mejora en el rendimiento de lectura. Mis proyectos están construidos usando CQS que me permite usar nHibernate para escrituras (comandos) y Dapper.net para lecturas (consultas). Esto me da el poder de nHibernate y un veloz y rápido lado de lectura.

Problemas que su equipo podría tener al peinar ambos:

  • la arquitectura del proyecto no es adecuada / difícil de hacer cambios
  • requiere trabajo adicional para escribir sql manualmente
  • requiere trabajo adicional para mapear entidades o crear y mapear DTO's
  • no hay un beneficio real al introducirlo

Si quiere hacerlo solo porque está cansado de nHibernate, tiene una buena razón para preocuparse.



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué