.net - studio - NHibernate: ¿asignar a campos o propiedades?

migraciones entity framework

Question

Cuando crea sus archivos de asignación, asigna sus propiedades a campos o propiedades:

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Foo" namespace="Foo.Bar" >
  <class name="Foo" table="FOOS" batch-size="100">
    [...]
    <property name="FooProperty1" access="field.camelcase" column="FOO_1" type="string" length="50" />
    <property name="FooProperty2" column="FOO_2" type="string" length="50" />
    [...]
  </class>
</hibernate-mapping>

Por supuesto, por favor explica por qué :)

Por lo general, hago un mapa de las propiedades, pero la asignación a los campos puede permitir poner algo de "lógica" en los getters / setters de las propiedades.

¿Es "malo" mapear en los campos? ¿Hay una mejor práctica?

Answer 1

Tiendo a estar de acuerdo con las respuestas anteriores. En general, mapea a las propiedades para casi todo, luego mapea a los campos para los recolectores de colecciones.
El único otro lugar al que te gustaría asignar los campos es cuando tienes algo:

public class AuditableEntity
{
   /*...*/
   DateTime creationDate = DateTime.Now;
   /*...*/
   public DateTime CreationDate { get { return creationDate; } }
}

Answer 2

Hago un mapa de las propiedades, no he encontrado la situación en la que me gustaría hacer un mapa de un campo ... y cuando lo hago, aumente mi diseño de BO para la necesidad. Creo que permite una mejor arquitectura.

Answer 3

Me asigno a las propiedades porque uso propiedades automáticas.

Excepto para las colecciones (como el set s. Las que access="field.camelcase-underscore" a los campos ( access="field.camelcase-underscore" ) porque no tengo propiedades públicas que las expongan, sino métodos.

Answer 4

Me mapeo a las propiedades. Si lo encuentro necesario, asigno el SETTER a un campo. (generalmente a través de algo como "access = field.camelcase").

Esto me permite tener consultas agradables, por ejemplo, "de People Where FirstName = ''John''" en lugar de algo como "from People where firstName / _firstName" y también evitar la lógica del setter al hidratar mis entidades.

Answer 5

Las propiedades también son útiles en caso de que necesite hacer algo funky con los datos a medida que entra y sale del almacenamiento persistente. En general, esto se debe evitar, pero a veces se necesitan algunos casos comerciales poco comunes o soporte heredado.

(Solo recuerde que si de alguna manera transforma los datos cuando vuelven a salir con el captador, NHibernate usará (por defecto) el retorno del captador y lo guardará de esa manera en la base de datos cuando la sesión se vacíe / cierre. esto es lo que quieres.)

Answer 6

Objetos nulos

Asignar campos puede ser útil si está implementando el patrón de objeto nulo si sus clases. Como esto no se puede realizar (fácilmente) cuando se asigna a Propiedades. Terminas teniendo que almacenar objetos falsos en la base de datos.

HQL

No estaba seguro de que con las consultas de HQL tuviera que cambiar los nombres de propiedad si estaba usando un enfoque de acceso de campo. es decir, si tuvieras <property name="FirstName" access="field.camelcase" /> pensé que aún podrías escribir "From Person where FirstName = :name"; ya que usaría el nombre de la propiedad todavía.

Puede encontrar más información sobre estrategias de campo y objetos nulos aquí .

Actuación

En relación con el rendimiento de campo vs propiedad en el blog de John Chapman Parece que no hay mucho problema en el rendimiento con conjuntos de resultados de rango pequeño y medio.

En resumen, cada enfoque tiene ciertas ventajas que pueden ser útiles dependiendo del escenario (el acceso de campo permite obtener solo de forma inmediata, sin necesidad de instaladores, el acceso a la propiedad funciona cuando no se requiere nada especial de su poco y parece ser el enfoque defacto, etc.)

Answer 7

Me asigno directamente a los campos, lo que me permite usar los ajustadores de propiedades para realizar un seguimiento del estado sucio de una propiedad.