¿Cuándo deberíamos elegir nHibernate sobre otros ORM?

Question

Lo confieso, no completamente grok * Hibernate.

Dado que los micro ORM como Dapper se pueden usar para abordar la mayoría de las necesidades de acceso a datos, ¿cuáles son los escenarios que requieren un arma grande como nHibernate? ¿Cuáles son algunos ejemplos de situaciones donde nHibernate brillaría? Para ser claros, no considero "la posibilidad de cambiar su base de datos sin cambiar el código" demasiada ventaja. En ocho años de programación, nunca tuve que hacer eso, y para empezar parece una pérdida de tiempo.

Estoy abierto a cualquier respuesta reflexiva, pero aquí hay algunos ejemplos de preguntas que tienen:

1. Cuando se consulta la API de la pena el trabajo extra que tiene que poner en la cartografía, en comparación con algo como Dapper?
2. ¿Cómo se puede aprovechar la carga lenta de una manera que limita el esfuerzo de desarrollo y simplemente funciona?
3. ¿Cuándo vale la pena el tiempo para averiguar cómo hacer un lote de extractos?
4. ¿En qué situación es mejor el sistema de caché que, por ejemplo, el almacenamiento en caché de salida de página? ¿Eso solo es cierto en entornos no distribuidos?
5. ¿Cómo se espera que un simple mortal como yo entienda cómo nHibernate podría funcionar en un entorno distribuido? Considere mezclar el almacenamiento en caché, el procesamiento por lotes y las sesiones sin estado, y piense en cómo los servidores web con equilibrio de carga manejarían todo eso.

Answer 1

Wow, gran pregunta. No estoy seguro de que un simple mortal pueda responderlo. Pero creo que estás siendo demasiado rápido para descartar "la posibilidad de cambiar tu base de datos". Hay muchos paquetes de software, tanto comerciales como de código abierto, que ofrecen la posibilidad de trabajar con diferentes RDBMS como una tienda de respaldo. Administrar el SQL para implementar en más de 2 plataformas de base de datos puede convertirse en una pesadilla absoluta, por lo que tener algo construir su SQL de una manera predecible (al menos en comparación con tenerlo escrito a mano) es una gran ventaja. Solo jugando al defensor del diablo, para algunas plataformas de bases de datos pude ver un crecimiento en el rendimiento de las transacciones, lo que hace que una opción de base de datos también sea prohibitivamente cara. La mayoría de los ORM te ayudarán con esto de una manera u otra, aunque tener una API de consulta enriquecida puede ser de gran ayuda cuando las necesidades de tu base de datos son lo suficientemente complejas.

La respuesta corta, creo, es que cuando su base de datos necesita una aplicación para alcanzar un cierto nivel de complejidad, el costo de cumplir con sus requisitos es inferior al costo de la curva de aprendizaje de nhibernate. No puedo ofrecer respuestas completas, pero trataré de dar mi opinión sobre los elementos de la lista.

1. Cuando está haciendo algo más que CRUD. La necesidad de consultas complejas en múltiples plataformas de bases de datos es probablemente un buen ejemplo. En este tipo de aplicaciones casi puedes terminar manteniendo dos bases de código separadas (bueno, realmente se desconectan si vas a la ruta de proceso almacenada) y puede haber valor para mantener todo tu código en .net (Es bueno poder unir prueba estas consultas con el resto de tu código, por ejemplo).
2. Además de los problemas que se observan en los entornos de confianza media, no estoy seguro de qué pasa con la carga diferida que "simplemente no funciona" ahora. El único problema con la carga lenta en mis ojos es que debe ser consciente de ello para evitar algunos de los problemas que pueden surgir al obtener grandes cantidades de datos, principalmente el problema de selección N + 1.
3. No necesita averiguar cómo crear extractos de lotes, solo necesita establecer un valor de configuración y olvidarse de ello.Esta es una optimización bastante grande que NHibernate hace por usted con un esfuerzo mínimo: su código puede ser mucho más limpio cuando solo está directamente relacionado con las operaciones y el control de las transacciones.
4. El almacenamiento en memoria caché de los datos devueltos puede ser beneficioso cuando se procesan sus páginas de manera diferente para diferentes usuarios, o haciendo cualquier tipo de procesamiento no trivial en su capa de dominio. Incluso en escenarios básicos, con el almacenamiento en caché de salida de página podría terminar teniendo la página de edición, la página de detalles, etc. en su caché, mientras que el almacenamiento en caché de sus datos más cerca de la fuente solo necesita almacenar en caché la entidad una vez. El almacenamiento en caché más cerca de la fuente también le brinda más protección contra el servicio de datos obsoletos. Una memoria caché orientada a datos también se puede compartir en varias aplicaciones, ya sea a través de servicios o apuntando nHibernate a una tienda fuera de proceso como memcached o redis. Esto puede ser tremendamente valioso en algunos entornos.
5. No estoy seguro de que necesite entender cómo funciona (muchas veces uso librerías de código abierto para protegerme de la necesidad de comprender los detalles de implementación de este tipo de cosas). Pero la respuesta corta es que ninguno de ellos se comporta de manera diferente en un escenario distribuido excepto en el almacenamiento en caché (y solo en el segundo nivel de almacenamiento en caché). Siempre que use un proveedor de caché distribuida (o apunte todos sus servidores al mismo proveedor de caché fuera de proceso) también debería ser bueno en ese frente.

Estoy hablando solo de nHibernate, pero imagino que para Hibernate la historia es muy parecida. Para aplicaciones de mayor escala y más complejas, puede haber un gran beneficio, pero hay una gran complejidad adicional que debe asumir para obtener este beneficio; aún así es probablemente menos complejo que implementar su propia solución para todos los problemas. * Hibernate resuelve para ti.

También tenía muchas preguntas sobre el almacenamiento en caché, parece. Sugiero leer más de this link para tener una idea de cómo funcionan las cachés de primer y segundo nivel. No voy a tratar de explicarlo aquí, porque parece que buscas una comprensión más profunda de la que puedo incluir en esta respuesta ya extensa :)

Answer 2

NHibernate es grande y potente, pero no tienes que saber todo al respecto tener éxito usándolo. Para responder a sus preguntas:

1. Todas las micro-NET ORMS no tienen ningún apoyo LINQ que yo sepa, y en lugar de confiar en la mezcla de cadenas SQL en el código. La creación de consultas con LINQ le proporciona seguridad de tipo, verificación en tiempo de compilación y gran capacidad de refactorización. Intente refactorizar una base de código con miles de consultas si todas las consultas utilizan cadenas SQL ... ¡sí! Y al refactorizar, me refiero a algo tan simple como agregar nuevas columnas, nuevas tablas, etc., que es algo que sucede todo el tiempo en un entorno empresarial. La refactoración de cadenas es posible, diablos eso es lo que la gente todavía tiene que hacer que confíe en los procedimientos almacenados, pero seguro que no elegiría hacer eso si tuviera seguridad de tipo a mi disposición.

2. Con la carga diferida, lo único que debe tener en cuenta es crear un escenario SELECT N + 1. Cada vez que tenga código haciendo un bucle foreach sobre un objeto/entidad de dominio, asegúrese de que la consulta que llenó el objeto o los objetos utilizó el método .Fetch() que simplemente crea un JOIN en SQL y rellena cualquier objeto hijo. De lo contrario, cuando busca el objeto y el punto en cualquier objeto secundario, el ORM tendrá que ejecutar otra instrucción SELECT para "recuperar" los datos. Básicamente, en la jerga de NHibernate, la búsqueda ansiosa es tu amiga.

3. Hacer un lote es tan fácil como un pastel con NHibernate. En su configuración de NHibernate, active el procesamiento por lotes y listo. Después de eso, si es necesario, puede ajustar el tamaño del lote en tiempo de ejecución para consultas particulares.

4. Nunca utilicé el almacenamiento en caché de segundo nivel.Trabajo en un gran entorno empresarial y nuestras aplicaciones funcionan muy rápido sin necesidad de almacenamiento en caché. Sin embargo, la memoria caché de primer nivel de NHibernate no requiere configuración y se puede considerar simplemente como un seguimiento de cambios. Básicamente, NHibernate mantiene internamente un diccionario de los objetos que ya ha recuperado de la base de datos y qué objetos están pendientes de guardar/actualizar en la base de datos. El caché de primer nivel es algo en lo que nunca pienso realmente, pero creo que es bueno saber a nivel rudimentario cómo funciona.

5. De nuevo, actualmente trabajo en un entorno empresarial y tenemos todo tipo de aplicaciones usando NHibernate; algunos bastante básicos y otros que usan todas las potentes funciones que NHibernate tiene para ofrecer. Sin embargo, lo que normalmente he visto en mi experiencia es que no todos los miembros del equipo deben ser expertos en NHibernate. Típicamente, de 1 a 3 desarrolladores estarán muy bien informados y los demás no se preocuparán por eso y solo crearán sus entidades, mapeos y continuarán con su programación. Una vez que la infraestructura está en su lugar y su organización ha resuelto los patrones que desea utilizar, todo es generalmente muy fácil.

pensamientos adicionales:

Un lugar que NHibernate realmente brilla es su capacidad para asignar cualquier tipo de diseño de base de datos loco que lanzar en él. Ahora no estoy diciendo que va a ser fácil mapear algún diseño de base de datos loco puesto a principios de los 90 donde tienes que unir un procedimiento almacenado y otra tabla juntos pero es posible. He hecho algunas asignaciones locas en mi día. Algunos incluso pensé que eran imposibles porque la base de datos simplemente no estaba diseñada para hacer lo que queríamos hacer, pero en todo momento, con persistencia, aún logro llevarlo a cabo con la increíble flexibilidad de NHibernate para mapear el diseño de una base de datos buena y mala.

Con Micro-ORMS, normalmente termina con un montón de cadenas de SQL incrustadas junto a su código. ¿Cómo se considera limpio y eficiente? Simplemente parece que lo que todas las personas están haciendo es poner lo que usan para poner en procedimientos almacenados en su código ahora. De hecho, sí uso Micro-ORM en algunos de mis proyectos, aunque tiene sentido, pero por lo general cuando solo estoy consultando sobre una tabla para algunos datos simples, sin cláusulas WHERE complicadas.

Para ser justos, soy una de esas personas que ha invertido bastante tiempo aprendiendo los entresijos de NHibernate pero no porque lo necesitaba para el trabajo, sino porque solo quería hacerlo. Trabajo con muchas personas en el trabajo que usan NHibernate todos los días y no lo obtienen del todo. Pero, de nuevo, no es necesario. Solo necesita saber algunas cosas básicas y está listo para comenzar.

Espero que esto ayude.