¿Con qué clases debo mapear con NHibernate?

Question

Actualmente, utilizamos nHibernate para asignar objetos comerciales a tablas de bases de datos. Dichos objetos comerciales hacen cumplir las reglas comerciales: los accesorios establecidos lanzarán una excepción en el acto si se viola el contrato para esa propiedad. Además, las propiedades hacen cumplir las relaciones con otros objetos (¡a veces bidireccionales!). Bueno, cada vez que nHibernate carga un objeto de la base de datos (por ejemplo, cuando se llama isession.get (id)), los accesorios establecidos de las propiedades asignadas se utilizan para colocar los datos en el objeto.

Lo bueno es que el nivel medio de la aplicación hace cumplir la lógica comercial. Lo malo es que la base de datos no. A veces, la mierda se abre paso en la base de datos. Si la basura se carga en la aplicación, rescata (lanza una excepción). A veces claramente debería rescatar porque no puede hacer nada, pero ¿qué pasa si puede seguir funcionando? Por ejemplo, una herramienta de administración que reúne informes en tiempo real corre un alto riesgo de fallar innecesariamente en lugar de permitir que un administrador incluso solucione un problema (potencial).

No tengo un ejemplo sobre mí en este momento, pero en algunos casos, dejar que Nhibernate use las propiedades de "puerta de entrada" que también aplican relaciones (especialmente Bidi) conducen a errores.

¿Cuáles son las mejores soluciones?

Actualmente,, por propiedad, crearé una "puerta trasera" solo para nHibernate:

public virtual int Blah {get {return _Blah;} set {/*enforces BR's*/}}
protected virtual int _Blah {get {return blah;} set {blah = value;}}
private int blah;

¡Mostré lo anterior en C# 2 (sin propiedades predeterminadas) para demostrar cómo esto nos consigue básicamente 3 capas o vistas a bla! Si bien esto ciertamente funciona, no parece ideal, ya que requiere que el BL proporcione una interfaz (pública) para la aplicación en general, y otra interfaz (protegida) para la capa de acceso de datos.

Hay un problema adicional: que yo sepa, nHibernate no le da una forma de distinguir entre el nombre de la propiedad en el BL y el nombre de la propiedad en el modelo de entidad (es decir, el nombre que usa cuando consulta, por ejemplo, a través de HQL-Cuando le dé a NHibernate el nombre (cadena) de una propiedad). Esto se convierte en un problema cuando, al principio, los BR para algunas propiedades bla, no son un problema, por lo que se refiere a él en su mapeo de O/R ... pero luego, debe agregar algunos BR que se convierten en un problema, así que Luego debe cambiar su mapeo O/R para usar una nueva propiedad _Blah, que rompe todas las consultas existentes usando "bla" (problema común con la programación contra cadenas).

¿Alguien ha resuelto estos problemas?

Answer 1

Si bien encontré la mayor parte de su arquitectura problemática, la forma habitual de lidiar con estas cosas es que Nhibernate use el campo de respaldo en lugar del setter.

En su ejemplo anterior, no necesita definir una propiedad protegida adicional. Solo usa esto en el mapeo:

<property name="Blah" access="nosetter.lowercase"/>

Esto se describe en los documentos, http://nhibernate.info/doc/nh/en/index.html#mapping-declaration-property (Tabla 5.1. Estrategias de acceso)