Hibernate Annotations - Which is better field or property access

Question

This question is somewhat related to Hibernate Annotation Placement Question   But I want to know which is better  Access via properties or access via fields  What are the advantages and disadvantages of each

User · Answer

Both        The EJB3 spec requires that you declare annotations on the element   type that will be accessed  i e  the getter method if you use property   access  the field if you use field access    https   docs jboss org hibernate annotations 3 5 reference en html single  entity-mapping

User · Answer

I prefer fields  but I ve run into one situation that seems to force me to place the annotations on getters   With the Hibernate JPA implementation   Embedded doesn t seem to work on fields  So that has to go on the getter  And once you put that on the getter  then the various  Column annotations have to go on the getters too   I think Hibernate doesn t want mixing fields and getters here   And once you re putting  Column on getters in one class  it probably makes sense to do that throughout

User · Answer

By default  JPA providers access the values of entity fields and map those fields to database columns using the entity   s JavaBean property accessor  getter  and mutator  setter  methods  As such  the names and types of the private fields in an entity do not matter to JPA  Instead  JPA looks at only the names and return types of the JavaBean property accessors  You can alter this using the  javax persistence Access annotation  which enables you to explicitly specify the access methodology that the JPA provider should employ    Entity  Access AccessType FIELD  public class SomeEntity implements Serializable           The available options for the AccessType enum are PROPERTY  the default  and FIELD  With PROPERTY  the provider gets and sets field values using the JavaBean property methods  FIELD makes the provider get and set field values using the instance fields  As a best practice  you should just stick to the default and use JavaBean properties unless you have a compelling reason to do otherwise   You can put these property annotations on either the private fields or the public accessor methods  If you use AccessType PROPERTY  default  and annotate the private fields instead of the JavaBean accessors  the field names must match the JavaBean property names  However  the names do not have to match if you annotate the JavaBean accessors  Likewise  if you use AccessType FIELD and annotate the JavaBean accessors instead of the fields  the field names must also match the JavaBean property names  In this case  they do not have to match if you annotate the fields  It   s best to just be consistent and annotate the JavaBean accessors for AccessType PROPERTY and the fields for AccessType FIELD   It is important that you should never mix JPA property annotations and JPA field annotations in the same entity  Doing so results in unspecified behavior and is very likely to cause errors

User · Answer

You should choose access via fields over access via properties  With fields you can limit the data sent and received  With via properties you can send more data as a host  and set G denominations  which factory set most of the properties in total

User · Answer

There are arguments for both  but most of them stem from certain user requirements  what if you need to add logic for   or  xxxx breaks encapsulation   However  nobody has really commented on the theory  and given a properly reasoned argument    What is Hibernate JPA actually doing when it persists an object - well  it is persisting the STATE of the object  That means storing it in a way that it can be easily reproduced    What is encapsulation  Encapsulations means encapsulating the data  or state  with an interface that the application client can use to access the data safely - keeping it consistent and valid    Think of this like MS Word  MS Word maintains a model of the document in memory - the documents STATE  It presents an interface that the user can use to modify the document - a set of buttons  tools  keyboard commands etc  However  when you choose to persist  Save  that document  it saves the internal state  not the set of keypresses and mouse clicks used to generate it    Saving the internal state of the object DOES NOT break encapsulation - otherwise you don t really understand what encapsulation means  and why it exists  It is just like object serialisation really    For this reason  IN MOST CASES  it is appropriate to persist the FIELDS and not the ACCESSORS  This means that an object can be accurately recreated from the database exactly the way it was stored  It should not need any validation  because this was done on the original when it was created  and before it was stored in the database  unless  God forbid  you are storing invalid data in the DB       Likewise  there should be no need to calculate values  as they were already calculated before the object was stored  The object should look just the way it did before it was saved  In fact  by adding additional stuff into the getters setters you are actually increasing the risk that you will recreate something that is not an exact copy of the original    Of course  this functionality was added for a reason  There may be some valid use cases for persisting the accessors  however  they will typically be rare  An example may be that you want to avoid persisting a calculated value  though you may want to ask the question why you don t calculate it on demand in the value s getter  or lazily initialise it in the getter  Personally I cannot think of any good use case  and none of the answers here really give a  Software Engineering  answer

User · Answer

i thinking about this and i choose method accesor   why    because field and methos accesor is the same but if later i need some logic in load field  i save move all annotation placed in fields  regards  Grubhart

User · Answer

I would strongly recommend field access and NOT annotations on the getters  property access  if you want to do anything more in the setters than just setting the value  e g  Encryption or calculation     The problem with the property access is that the setters are also called when the object is loaded  This has worked for me fine for many month until we wanted to introduce encryption  In our use case we wanted to encrypt a field in the setter and decrypt it in the getter   The problem now with property access was that when Hibernate loaded the object it was also calling the setter to populate the field and thus was encrypting the encrypted value again   This post also mentions this   Java Hibernate  Different property set function behavior depending on who is calling it  This has cause me headaches until I remembered the difference between field access and property access  Now I have moved all my annotations from property access to field access and it works fine now

User · Answer

To make your classes cleaner  put the annotation in the field then use  Access AccessType PROPERTY

User · Answer

Let me try to summarize the most important reasons for choosing field-based access  If you want to dive deeper  please read this article on my blog  Access Strategies in JPA and Hibernate     Which is better  field or property access   Field-based access is by far the better option  Here are 5 reasons for it   Reason 1  Better readability of your code  If you use field-based access  you annotate your entity attributes with your mapping annotations  By placing the definition of all entity attributes at the top of your class  you get a relatively compact view of all attributes and their mappings   Reason 2  Omit getter or setter methods that shouldn   t be called by your application  Another advantage of field-based access is that your persistence provider  e g   Hibernate or EclipseLink  doesn   t use the getter and setter methods of your entity attributes  That means that you don   t need to provide any method that shouldn   t be used by your business code  This is most often the case for setter methods of generated primary key attributes or version columns  Your persistence provider manages the values of these attributes  and you should not set them programmatically   Reason 3  Flexible implementation of getter and setter methods  Because your persistence provider doesn   t call the getter and setter methods  they are not forced to fulfill any external requirements  You can implement these methods in any way you want  That enables you to implement business-specific validation rules  to trigger additional business logic or to convert the entity attribute into a different data type   You can  for example  use that to wrap an optional association or attribute into a Java Optional   Reason 4  No need to mark utility methods as  Transient  Another benefit of the field-based access strategy is that you don   t need to annotate your utility methods with  Transient  This annotation tells your persistence provider that a method or attribute is not part of the entity persistent state  And because with field-type access the persistent state gets defined by the attributes of your entity  your JPA implementation ignores all methods of your entity   Reason 5  Avoid bugs when working with proxies  Hibernate uses proxies for lazily fetched to-one associations so that it can control the initialization of these associations  That approach works fine in almost all situations  But it introduces a dangerous pitfall if you use property-based access   If you use property-based access  Hibernate initializes the attributes of the proxy object when you call the getter method  That   s always the case if you use the proxy object in your business code  But quite a lot of equals and hashCode implementations access the attributes directly  If this is the first time you access any of the proxy attributes  these attributes are still uninitialized

User · Answer

I prefer field access  because that way I m not forced to provide getter setter for each property   A quick survey via Google suggests that field access is the majority  e g   http   java dzone com tips 12-feb-jpa-20-why-accesstype    I believe field access is the idiom recommended by Spring  but I can t find a reference to back that up   There s a related SO question that tried to measure performance and came to the conclusion that there s  no difference

User · Answer

Are we there yet  That s an old presentation but Rod suggests that annotation on property access encourages anemic domain models and should not be the  default  way to annotate

User · Answer

I think annotating the property is better because updating fields directly breaks encapsulation  even when your ORM does it   Here s a great example of where it will burn you  you probably want your annotations for hibernate validator  amp  persistence in the same place  either fields or properties    If you want to test your hibernate validator powered validations which are annotated on a field  you can t use a mock of your entity to isolate your unit test to just the validator  Ouch

User · Answer

We created entity beans and used getter annotations  The problem we ran into is this  some entities have complex rules for some properties regarding when they can be updated  The solution was to have some business logic in each setter that determines whether or not the actual value changed and  if so  whether the change should be allowed  Of course  Hibernate can always set the properties  so we ended up with two groups of setters  Pretty ugly   Reading previous posts  I also see that referencing the properties from inside the entity could lead to issues with collections not loading   Bottom line  I would lean toward annotating the fields in the future

User · Answer

Normally beans are POJO  so they have accessors anyway    So the question is not  which one is better    but simply  when to use field access    And the answer is  when you don t need a setter getter for the field

User · Answer

AccessType PROPERTY  The EJB persistence implementation will load state into your class via JavaBean  setter  methods  and retrieve state from your class using JavaBean  getter  methods  This is the default   AccessType FIELD  State is loaded and retrieved directly from your class  fields  You do not have to write JavaBean  getters  and  setters

User · Answer

I believe property access vs  field access is subtly different with regards to lazy initialisation   Consider the following mappings for 2 basic beans    lt hibernate-mapping package  org nkl model  default-access  field  gt     lt class name  FieldBean  table  FIELD BEAN  gt       lt id name  id  gt         lt generator class  sequence    gt       lt  id gt       lt property name  message    gt     lt  class gt   lt  hibernate-mapping gt    lt hibernate-mapping package  org nkl model  default-access  property  gt     lt class name  PropBean  table  PROP BEAN  gt       lt id name  id  gt         lt generator class  sequence    gt       lt  id gt       lt property name  message    gt     lt  class gt   lt  hibernate-mapping gt    And the following unit tests    Test public void testFieldBean         Session session   sessionFactory openSession        Transaction tx   session beginTransaction        FieldBean fb   new FieldBean  field        Long id    Long  session save fb       tx commit        session close         session   sessionFactory openSession        tx   session beginTransaction        fb    FieldBean  session load FieldBean class  id       System out println fb getId         tx commit        session close        Test public void testPropBean         Session session   sessionFactory openSession        Transaction tx   session beginTransaction        PropBean pb   new PropBean  prop        Long id    Long  session save pb       tx commit        session close         session   sessionFactory openSession        tx   session beginTransaction        pb    PropBean  session load PropBean class  id       System out println pb getId         tx commit        session close        You will see the subtle difference in the selects required   Hibernate       call next value for hibernate sequence Hibernate       insert      into         FIELD BEAN          message  id       values                Hibernate       select         fieldbean0  id as id1 0           fieldbean0  message as message1 0       from         FIELD BEAN fieldbean0       where         fieldbean0  id   0 Hibernate       call next value for hibernate sequence Hibernate       insert      into         PROP BEAN          message  id       values                1   That is  calling fb getId   requires a select  whereas pb getId   does not

User · Answer

I tend to prefer and to use property accessors    I can add logic if the need arises  as mentioned in the accepted answer   it allows me to call foo getId   without initializing a proxy  important when using Hibernate  until HHH-3718 get resolved     Drawback    it makes the code less readable  you have for example to browse a whole class to see if there are  Transient around there

User · Answer

Here s a situation where you HAVE to use property accessors   Imagine you have a GENERIC abstract class with lots of implementation goodness to inherit into 8 concrete subclasses   public abstract class Foo lt T extends Bar gt         T oneThing      T anotherThing          getters and setters ommited for brevity         Lots and lots of implementation regarding oneThing and anotherThing here      Now exactly how should you annotate this class   The answer is YOU CAN T annotate it at all with either field or property access because you can t specify the target entity at this point   You HAVE to annotate the concrete implementations   But since the persisted properties are declared in this superclass  you MUST used property access in the subclasses   Field access is not an option in an application with abstract generic super-classes

User · Answer

That really depends on a specific case -- both options are available for a reason  IMO it boils down to three cases    setter has some logic that should not be executed at the time of loading an instance from a database  for example  some value validation happens in the setter  however the data coming from db should be valid  otherwise it would not get there       in this case field access is most appropriate  setter has some logic that should always be invoked  even during loading of an instance from db  for example  the property being initialised is used in computation of some calculated field  e g  property -- a monetary amount  calculated property -- a total of several monetary properties of the same instance   in this case property access is required  None of the above cases -- then both options are applicable  just stay consistent  e i  if field access is the choice in this situation then use it all the time in similar situation

User · Answer

I had the same question regarding accesstype in hibernate and found some answers here

User · Answer

I prefer using field access for the following reasons   The property access can lead to very nasty bugs when implementing equals hashCode and referencing fields directly  as opposed through their getters   This is because the proxy is only initialized when the getters are accessed  and a direct-field access would simply return null   The property access requires you to annotate all utility methods  e g  addChild removeChild  as  Transient   With field access we can hide the  Version field by not exposing a getter at all  A getter can also lead to adding a setter as well  and the version field should never be set manually  which can lead to very nasty issues   All version incrementation should be triggered through OPTIMISTIC FORCE INCREMENT or PESSIMISTIC FORCE INCREMENT explicit locking

User · Answer

I prefer accessors  since I can add some business logic to my accessors whenever I need  Here s an example    Entity public class Person       Column  nickName     public String getNickName         if this name    null  return generateFunnyNick this name        else return  John Doe           Besides  if you throw another libs into the mix  like some JSON-converting lib or BeanMapper or Dozer or other bean mapping cloning lib based on getter setter properties  you ll have the guarantee that the lib is in sync with the persistence manager  both use the getter setter

User · Answer

Another point in favor of field access is that otherwise you are forced to expose setters for collections as well what  for me  is a bad idea as changing the persistent collection instance to an object not managed by Hibernate will definitely break your data consistency   So I prefer having collections as protected fields initialized to empty implementations in the default constructor and expose only their getters  Then  only managed operations like clear    remove    removeAll   etc are possible that will never make Hibernate unaware of changes

User · Answer

I favor field accessors   The code is much cleaner  All the annotations can be placed in one section of a class and the code is much easier to read     I found another problem with property accessors  if you have getXYZ methods on your class that are NOT annotated as being associated with persistent properties  hibernate generates sql to attempt to get those properties  resulting in some very confusing error messages   Two hours wasted   I did not write this code  I have always used field accessors in the past and have never run into this issue   Hibernate versions used in this app    lt  -- hibernate -- gt   lt hibernate-core version gt 3 3 2 GA lt  hibernate-core version gt   lt hibernate-annotations version gt 3 4 0 GA lt  hibernate-annotations version gt   lt hibernate-commons-annotations version gt 3 1 0 GA lt  hibernate-commons-annotations version gt   lt hibernate-entitymanager version gt 3 4 0 GA lt  hibernate-entitymanager version gt

User · Answer

I have solved lazy initialisation and field access here Hibernate one-to-one  getId   without fetching entire object

[java] Hibernate Annotations - Which is better, field or property access?

Examples related to java

Examples related to hibernate

Examples related to orm

Examples related to jpa

Examples related to annotations