NHibernate : map to fields or properties?

Question

When you create your mapping files, do you map your properties to fields or properties :

Answer 1

I map to properties, I haven't come across the situation where I would map to a field... and when I have I augment my B.O. design for the need. I think it allows for better architecture.

Answer 2

Null Objects

Mapping to fields can be useful if you are implementing the null object pattern if your classes. As this cannot be performed (easily) when mapping to Properties. You end up having to store fake objects in the database.

HQL

I was unsure that with HQL queries you had to change the property names if you were using a field access approach. ie if you had <property name="FirstName" access="field.camelcase" /> I thought you could still write "From Person where FirstName = :name"; as it would use the property name still.

Further discussion on field strategies and Null object can be found here.

Performance

In relation to performance of field vs property on John Chapman's blog It appears there isn't much of an issue in performance with small-midrange result sets.

In summary, each approach has certain perks that may be useful depending on the scenario (field access allows readonly getters, no need for setters, property access works when nothing special is required from your poco and seems to be the defacto approach. etc)

Answer 3

Properties are also useful in the case you need to do something funky with the data as it comes in and out of persistant storage. This should generally be avoided, but some rare business cases or legacy support sometimes calls for this.

(Just remember that if you somehow transform the data when it comes back out with the getter, NHibernate will (by default) use the return from the getter and save it that way back to the database when the Session is flushed/closed. Make sure that is what you want.)

Answer 4

I map to properties. If I find it necessary, I map the SETTER to a field. (usually via something like "access=field.camelcase").

This lets me have nice looking Queries, e.g. "from People Where FirstName = 'John'" instead of something like "from People Where firstName/_firstName" and also avoid setter logic when hydrating my entities.

Answer 5

I map to properties because I use automatic properties.

Except for collections (like sets. Those I map to fields (access="field.camelcase-underscore") because I don't have public properties exposing them, but methods.

Answer 6

I map directly to fields, which allows me to use the property setters to keep track of a property's dirty state.