NHibernate: mappa per campi o proprietà?

Question

Quando si creano i file di mappatura, si mappano le proprietà su campi o proprietà:

<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>

Certo, per favore spiega perché :)

Di solito, eseguo il mapping alle proprietà, ma il mapping ai campi può consentire di inserire un po '" logica " nei getter / setter delle proprietà.

È " cattivo " mappare ai campi? Esiste una buona pratica?

Answer 1

I mappare alle proprietà. Se lo trovo necessario, associo il SETTER a un campo. (di solito tramite qualcosa come " access = field.camelcase ").

Questo mi permette di avere query carine, ad es. " from People Where FirstName = 'John' " invece di qualcosa come " da People Where firstName / _firstName " ed evita anche la logica dei setter quando idrati le mie entità.

Answer 2

Le proprietà sono utili anche nel caso in cui sia necessario fare qualcosa di strano con i dati quando entrano e escono dalla memoria persistente. Questo dovrebbe generalmente essere evitato, ma alcuni casi aziendali rari o il supporto legacy a volte lo richiedono.

(Ricorda solo che se in qualche modo trasformi i dati quando vengono restituiti con il getter, NHibernate utilizzerà (di default) il ritorno dal getter e lo salverà nel database quando la sessione viene scaricata / chiusa. Assicurati che sia quello che vuoi.)

Answer 3

Mappo sulle proprietà, non ho riscontrato la situazione in cui avrei mappato un campo ... e quando ho aumentato il mio B.O. progettare per il bisogno. Penso che permetta una migliore architettura.

Answer 4

Mappo sulle proprietà perché utilizzo le proprietà automatiche.

Tranne le raccolte (come set s. Quelle che associo ai campi (access="field.camelcase-underscore") perché non ho proprietà pubbliche che le espongono, ma metodi.

Answer 5

Oggetti null

Il mapping ai campi può essere utile se stai implementando il modello di oggetti null se le tue classi . Poiché ciò non può essere eseguito (facilmente) durante il mapping su Proprietà. Alla fine devi archiviare oggetti falsi nel database.

HQL

Non ero sicuro che con le query HQL dovevi cambiare i nomi delle proprietà se stavi usando un approccio di accesso ai campi. vale a dire se avessi <property name="FirstName" access="field.camelcase" /> pensavo che avresti ancora potuto scrivere "From Person where FirstName = :name"; poiché avrebbe usato ancora il nome della proprietà.

Ulteriori discussioni sulle strategie di campo e sull'oggetto Null sono disponibili qui .

Performance

In relazione all'esecuzione del campo rispetto alla proprietà sul Blog di John Chapman Sembra che non ci siano molti problemi nelle prestazioni con set di risultati di fascia medio piccola.

In sintesi, ogni approccio ha alcuni vantaggi che possono essere utili a seconda dello scenario (l'accesso al campo consente di ottenere immediatamente, senza necessità di setter, l'accesso alla proprietà funziona quando non è richiesto nulla di speciale dal tuo poco e sembra essere l'approccio defacto. etc)

Answer 6

Tendo ad essere d'accordo con le risposte sopra. In genere, mappare le proprietà per quasi tutto, quindi mappare i campi per i setter di raccolte.
L'unico altro posto che vorresti mappare sui campi è quando hai qualcosa:

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

Answer 7

Mappo direttamente sui campi, il che mi consente di utilizzare i setter di proprietà per tenere traccia dello stato sporco di una proprietà.