Geek Answers Handbook

NHibernate: why field.camelcase?

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 can we do this” and not “what does this mean.” I think this could be a source of bugs for developers.

+4
source share
3 answers

I think you're wondering what to use field.camelcase when we can do the same with just a field? This is true, but it would give (NH) properties unintayive names when, for example, writing queries or referencing a property from other mappings.

Say you have something you want to match using a field, like

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

You can match the field using the field, but then you have to write "_name" when, for example, HQL queries are written.

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

If you use the field.camelcase file instead, the same query will look like

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

EDIT Now I saw that you wrote "field.camelcase", but my answer is "field.camelcase-underscore". The principles are the same, and I think you get the point;)

+5
source

part after '.' this is the so-called naming strategy that you must specify when the name you write in hbm differs from the support field. In the case of field.camelcase you are allowed to write CustomerName in hbm, and NHibernate will look for a field named CustomerName in the class. The reason for this is that NHibernate does not force you to choose a naming convention that will meet the requirements, NH will work with almost any naming convention.

+3
source

There are cases where properties are not suitable for NH for setting values.

They can

  • has no setter at all
  • connection check on data that is installed that are not used when loading from the database
  • perform some other actions that are used only when the value is changed by business logic (for example, setting other properties).
  • converts the value in some way, which will cause NH to perform unnecessary updates.

Then you do not want NH to call setter. Instead of matching the field, you are matching the property anyway, but tell NH to use this field when reading / writing a value. Roger has a good explanation of why mapping properties is good.

0
source

More articles:


All Articles