¿Cuáles son los errores y antipatrones más comunes que cometen los programadores de usuarios de NHibernate?

28

¿Cuáles son los errores y antipatrones más comunes que cometen los programadores de usuarios de NHibernate? Explique por qué esas son malas prácticas o proporcione un enlace al recurso para leer más.

Por ejemplo:

  • Un antipatrón común para los nuevos programadores de NHibernate es usar identidades / POID nativos en lugar de los estilos ORM. Leer más aquí...
nhibernate Darius Kucinskas
fuente
1
Puede encontrar algunos de los errores comunes aquí: Alertas
1
También hay algunas publicaciones valiosas aquí sobre las trampas de NHibernate

Respuestas:

34

Mis problemas personales "explicados con frecuencia":

Antipatrones

Jugueteando con objetos separados (SaveOrUpdate o Merge más algún código desordenado) en lugar de usar DTO. Cuanto más complejas son las entidades, más desordenado es el código. (También significa que funciona bastante bien con entidades triviales). Ayende también lo llama el Patrón Stripper y explica el problema de encapsulación.

No entender la ignorancia de persistencia y escribir aplicaciones NH como cuando se usa SQL explícito. Síntoma de eso: llamando a Update después de cambiar un objeto, preguntándose por qué persisten los cambios, incluso si no se ha llamado a Update, preguntándose cómo evitar que los cambios persistan.

No comprende las transacciones y el patrón de la unidad de trabajo . Anti-patrones frecuentes: transacciones implícitas, sesión por operación y sesión por aplicación. Un poco más de lectura:

Uso de eventos NH para poner la lógica de la aplicación (p. Ej., Seguimiento de cambios en disparadores de inserción y actualización)

Crea una clase por mesa . Algunas personas no entienden OOD, otras no entienden el diseño relacional.

Errores

uso de uno a uno en lugar de muchos a uno. Intenté explicarlo en esta respuesta .

Usando join fetch en combinación con SetMaxResult. Mis últimas respuestas relacionadas con ese tema:

Escritura de entidades auto cambiantes . Cuando una entidad no devuelve exactamente el valor establecido por NH, se considera sucio y se actualiza en cada sesión. Por ejemplo: reemplazar la colección persistente NH en un establecedor de propiedades.

  IList<Address> Addresses
  {
    get { return addresses; }
    // will cause the addresses collection to be built up from scratch
    // in the database in every session, even when just reading the entity.
    set { addresses = new List<Address>(value); }
  }

  int Whatever
  {
    // will make the entity dirty after reading negative values from the db.
    // this causes unexpected updates after just reading the entity.
    get { if (whatever < 0) return 0; }
    set { whatever = value; }
  }

Puede ser más está siguiendo.

Stefan Steinegger
fuente
2
+1: Debería agregar "No usar el patrón de Unidad de trabajo" y "Una sesión por aplicación" en mi lista.
Falcon
@ Falcon: sí, probablemente. Es un problema general de "no entender las transacciones". La unidad de trabajo está un poco cubierta por la ignorancia de persistencia. Aunque son conceptos completamente diferentes, dan como resultado los mismos patrones.
Stefan Steinegger
5

El "problema de Seleccionar N + 1 ".

Aquí es donde termina ejecutando una selección para cada entidad que desea manipular (N), y una selección para obtener la lista de entidades (+1), en lugar de una sola selección de todas las entidades y sus atributos.

Sean McMillan
fuente
1
  • Demasiadas abstracciones
  • No usar Automappings con FluentNHibernate
Astuto
fuente
El primer punto es un poco vago, pero en caso de que se esté refiriendo a nociones tontas como ocultar ISession detrás de un "Repositorio" o "DAO", estoy de acuerdo.
Chris
1
El segundo punto, sin embargo, no tiene sentido. Hay buenas razones por las que a menudo queremos tener un control detallado sobre el modelo de datos físicos y poder desacoplarlo del modelo de dominio. Después de todo, ese es el punto de la "M" en "ORM". El uso de aplicaciones automáticas (aunque es útil en escenarios simples) lo vence. Además, también está el problema de los esquemas de integración de bases de datos heredadas, para los cuales la creación automática de datos es inútil.
Chris
Yo uso el mapeo basado en convenciones de código incorporado. Maneja una gran franja de basura que de lo contrario tendría que repetir. Sin embargo, todavía ofrece la libertad de personalizar personalizaciones específicas de la entidad que se superponen a la asignación generada por convención. Es super útil.
Sam
1

Intentando abstraerlo para que pueda cambiar a Entity Framework (o algo más) en una fecha posterior.

Esto es mucho, mucho más difícil de lo que la mayoría de las personas que lo intentan se dan cuenta. Existen numerosas diferencias entre los dos que pueden hacerte tropezar de maneras que a veces pueden ser bastante sutiles. También es muy poco común que sea realmente necesario al final, tanto así que puede estar intentando implementarlo meticulosamente durante años antes de descubrir que su enfoque está completamente equivocado.

Además, le restringe el uso de una gran cantidad de funciones útiles e importantes de NHibernate, como el almacenamiento en caché de segundo nivel, la interceptación, la gestión de concurrencia, el seguimiento de cambios, las consultas de captación previa, etc.

Si realmente existiera una necesidad válida de cambiar entre NHibernate y Entity Framework, habría un proyecto desarrollado activamente para respaldar esto en GitHub (quizás algo similar a CommonServiceLocator) con numerosos contribuyentes y solicitudes de extracción.

jammycakes
fuente