NHibernate: why field.camelcase?

Question

Can someone tell me why in NHibernate mapping we can set access="field.camelcase", since we have access="field" and access="property"?

EDIT: my question is "why we can do this", not "what does it mean". I think this can be source of error for developper.

Answer 1

I guess you wonder what use field.camelcase have when we can do the same with just field? That's true, but that would give (NH) properties unintuive names when eg writing queries or reference the property from other mappings.

Let's say you have something you want to map using the field, eg

private string _name;
public string Name { get { return _name; } }

You sure can map the field using "field" but then you would have to write "_name" when eg writing HQL queries.

select a from Foo a where a._name = ...

If you instead using field.camelcase the data, the same query would look like

select a from Foo a where a.Name...

EDIT I now saw you wrote "field.camelcase" but my answer is about "field.camelcase-underscore". The principles are the same and I guess you get the point ;)

Answer 2

the portion after the '.' is the so called naming strategy, that you should specify when the name you write in the hbm differ from the backing field. In the case of field.camelcase you are allowed to write CustomerName in the hbm, and NHibernate would look for a field with name customerName in the class. The reason for that is NHibernate not forcing you to choose a name convention to be compliant, NH will works with almost any naming convention.

Answer 3

There are cases where the properties are not suitable for NH to set values.

They may

• have no setter at all
• call validation on the data that is set, which is not used when loading from the database
• do some other stuff that is only used when the value is changed by the business logic (eg. set other properties)
• convert the value in some way, which would cause NH performing unnecessary updates.

Then you don't want NH to call the property setter. Instead of mapping the field, you still map the property, but tell NH to use the field when reading / writing the value. Roger has a good explanation why mapping the property is a good thing.