4

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.

Francois
  • 10,730
  • 7
  • 47
  • 80

3 Answers3

5

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

Roger
  • 1,944
  • 1
  • 11
  • 17
  • Ok, but in this case you use `access="property"`. Because "Name" + field.case = "name", not "_name", right? – Francois Jul 06 '12 at 08:48
  • +1 Exactly. It makes queries independent of mapping details. You may also change the way NH accesses the properties / fields without changing any queries. This is pure maintainability. – Stefan Steinegger Jul 06 '12 at 08:50
  • @FrancoisB. No, you couldn't use "property" because there is no setter (you could have used "nosetter.xxx" instead). – Roger Jul 06 '12 at 08:54
  • Thanks. In fact, field.camelcase is great when: 1/ you don't have setter 2/ you want HQL with property style naming. – Francois Jul 06 '12 at 09:27
3

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.

Felice Pollano
  • 32,832
  • 9
  • 75
  • 115
  • 2
    I know that. But my question is why NHibernate allows this 3 ways that can be confusing. – Francois Jul 06 '12 at 08:42
  • 1
    they are not equivalent, the naming strategy after the dot changes the behavior – Felice Pollano Jul 06 '12 at 08:45
  • not equivalent? CustomerName + field.camelcase = customerName = field, isn't it? – Francois Jul 06 '12 at 08:49
  • 1
    no because if you use field CustromerName is expected as a field: the case is preserved. – Felice Pollano Jul 06 '12 at 08:52
  • I think we don't understand each other :) If field.camecase means the field with the same name as the property, but with a lowercase for the first letter, what is the point of using field.camecase, and not field directly, since we target the field and not the property. – Francois Jul 06 '12 at 08:54
  • @FrancoisB. if you use fiel alone, you should specify the exact case in the hbm as in the class – Felice Pollano Jul 06 '12 at 08:56
0

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.

Community
  • 1
  • 1
Stefan Steinegger
  • 63,782
  • 15
  • 129
  • 193