Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Hibernate: Accessors vs. Direct Field Access

 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've recently begun a project to convert an EJB application (session and entity) to Hibernate and have an architecture question for those that have blazed ahead.

I've read in a few places now that using accessor methods is recommended over direct field access for the mappings. However, this makes my public accessors less elegant than I had hoped. When a client calls a setter, I want to apply validation checks (not null, cannot overwrite existing non-null value, etc), but I don't want those to interfere with Hibernate loading an object from the database.

One solution I see is to have two sets of accessors: one set for clients and another stripped-down set for Hibernate. However, it seems no different at that point from using direct field access.

What have others found with both methods, and are there any particular gotchas when using direct field access?

Thanks!
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David I have used another strategy: if a have the model class Foo manipulated by Hibernate that I expose to the client a FooExt which provides validation.

./pope
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ali Pope:
if a have the model class Foo manipulated by Hibernate that I expose to the client a FooExt which provides validation.
The validation I'm doing is more along the lanes of null/can-only-set-once rather than formatting. User entries will be validated with Commons Validator, but I want to be able to enforce some basic assertions at the business object layer.

After Christian's reply on the Hibernate forum, I tried using direct field access and have had no trouble. So my setters now apply the logic above and Hibernate bypasses them.
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David can you point me to the Christian's answer pls? I am very interested in an author suggestion .

./pope
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ali Pope:
David can you point me to the Christian's answer pls? I am very interested in an author suggestion
Gladly, but you'll probably be a bit disappointed. Here is the thread, but Christian's entire reply was
Christian Bauer on Hibernate forums:
Nope, no gotchas.
Indeed, I have had no troubles so far using direct field access for properties and relationships for six entities.
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks David . Your comment was interesting as it seems I have missed that little quote. Thinking further I can say that I cannot see any problems in this approach and I even find it more easy to implement over my way.

./pope
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I posed the question as I remembered reading somewhere fairly authoritative that the Hibernate team recommends using property accessors instead of direct field access. I couldn't find the reference, and I didn't recall a reason, so I asked.

I was thinking maybe there are certain mappings that won't work with DFA, but I can't think of anything that would make that so. In any case, DFA works and makes more sense to me as I need to distinguish between the business logic setting a property and the persistence layer materializing entities.

Thanks!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic