I'd like to know the answer to this simple question.
When I create an entity object and I want to restrict a setting of an attribute (for example I don't want to allow anyone to set an integer value less then 1 to an attribute), should I implement it in the setter of this attribute or should I check this restriction latter in a class that handles these objects ? Generally, can I implement getters and setters however I want as long as my getters return and setters set attributes ?
I know there are some rules (code conventions) in java, so I don't want to break any of them.
Thanks in advance, hope that my question is clear enough and sorry for any grammar mistakes I might have made :/ .
Yes getters/setters are useful for that.
for example:
public void setAge(int age){
if(age < 0){
throw new IllegalArgumentException("Invalid age : " + age);
//or if you don't want to throw an exception you can handle it otherways too
}
}
You can also use Java-EE's Bean Validators for this
public class Person{
#Min(value = 0)
#Max(value = 99)
private Integer age;
//some other code
}
My preferred approach is to use JSR 303 (Bean Validation API) to ensure that the properties of the class are valid.
It is quite alright to perform validation in setters, but this is not always a desirable approach. There is the potential of mixing the needs of several contexts that are not related to each other. For example, some of your properties must never be set from the user-interface, and would instead be computed by a service, before being persisted. In such an event, it is not desirable to have this logic inside a setter, for you would need to know the context in which the setter is being invoked; you'll need to apply different rules in your UI layer and in your persistence layer. JSR 303 allows you to separate these concerns using validation groups, so that your UI validation group is different from your persistence validation group.
In JPA 2.0, when you annotate your class using constraints that are evaluated by a JSR 303 validator, your persistence provider can automatically evaluate these constraints on the PrePersist, PreUpdate and PreRemove (typically not done; see below) lifecycle events of entities. To perform validation of entities in your JPA provider, you must specify either the validation-mode element or the javax.persistence.validation.mode property in your persistence.xml file; the values must be either AUTO (the default) or CALLBACK (and not NONE).
The presence of a Bean Validation provider is sufficient to ensure that validation occurs on JPA entity lifecycle events, as the default value is AUTO. You get this by default, in a Java EE 6 application server; Glassfish uses the RI implementation of JSR 303 which is Hibernate Validator, and it works quite well with EclipseLink as well.
The CALLBACK mode will allow you to override the validation groups that are to be applied when the lifecycle events are triggered. By default, the default Bean validation group (Default) will be validated for update and persist events; the remove event does not involve any validation. The CALLBACK mode allows you to specify a different validation group for these events, using the properties javax.persistence.validation.group.pre-persist, javax.persistence.validation.group.pre-update and javax.persistence.validation.group.pre-remove.
Do keep in mind that JSR 303 validation can be used outside a Java EE container, although the Bean Validation API documentation link that I've posted above is from the Java EE 6 API documentation.
This is the goal of getters and setters.
If we cannot add some behavior in these methods, well... why don't we use public attributes ?
From my understanding of your question, it pretty much related to encapsulation OO principle.
You can have a look at this article: http://www.tutorialspoint.com/java/java_encapsulation.htm
Getters and setters are great for adding the restrictions, just like Jigar Joshi has in his answer. That way you get feedback immediately and can handle the problem when it is introduced.
Another solution would be to use object validation (something like a JSR-303 implementation) which would allow you to annotate the field with a min and max values. Something like
#Min(value=1)
private int myvalue;
Then you can validate the entire object in one go and get all messages if you have other constrained fields. This is obviously not useful everywhere, but if it fits your need it is an option.
Finally, when you say "entity" I think of something stored in a database or related to ORM tools. If that is the case, you will want to be careful with what you do in your getter. For instance, if you do lazy initialization in the getter some ORM suppliers will mark the entity as dirty and attempt to flush it to the database possibly causing an unintended write.
Related
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?
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.
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".
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<T extends Bar> {
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.
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.
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).
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.
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.
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).
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.
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 & 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.
I believe property access vs. field access is subtly different with regards to lazy initialisation.
Consider the following mappings for 2 basic beans:
<hibernate-mapping package="org.nkl.model" default-access="field">
<class name="FieldBean" table="FIELD_BEAN">
<id name="id">
<generator class="sequence" />
</id>
<property name="message" />
</class>
</hibernate-mapping>
<hibernate-mapping package="org.nkl.model" default-access="property">
<class name="PropBean" table="PROP_BEAN">
<id name="id">
<generator class="sequence" />
</id>
<property name="message" />
</class>
</hibernate-mapping>
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.
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.
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.
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.
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.
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:
<!-- hibernate -->
<hibernate-core.version>3.3.2.GA</hibernate-core.version>
<hibernate-annotations.version>3.4.0.GA</hibernate-annotations.version>
<hibernate-commons-annotations.version>3.1.0.GA</hibernate-commons-annotations.version>
<hibernate-entitymanager.version>3.4.0.GA</hibernate-entitymanager.version>
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).
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!".
I had the same question regarding accesstype in hibernate and found some answers here.
I have solved lazy initialisation and field access here Hibernate one-to-one: getId() without fetching entire object
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.
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
To make your classes cleaner, put the annotation in the field then use #Access(AccessType.PROPERTY)
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
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".
I'm wondering whether it is possible to add additional functionality to the #Column annotation in JPA. Specifically, what I would like to do is tag columns of sensitive data with an #ProtectedColumn annotation: this would then tell the persistence framework to apply some type of data protection (encryption, tokenization, whatever...) to the values when storing them into the actual data store, and then reverse that process when reading the values from the data store.
So I might have a Customer class that included this code:
#Column(value="Name")
private String name;
#ProtectedColumn(value="CreditCardNumber", protectionType="ultra")
private String creditCardNumber;
Instead of storing the actual credit card number, this would then store the result of protecting the credit card number with the protection type "ultra" (whatever that may be).
Obviously, I don't want to re-implement all the database access functionality already present in the #Column annotation: I just want to extend its functionality. I know that annotations are not directly extensible (see Why is not possible to extend annotations in Java?), but it seems to me that it might be possible to intercept the value before it gets to the #Column annotation, so perhaps the field definition looks like this:
#Protected(protectionType="ultra")
#Column(value="CreditCardNumber")
private String creditCardNumber;
So my first question is whether this is even theoretically possible: if so, I'd appreciate any pointers on how to combine/extend annotations in this way.
You can use a converter. For example you can implement a Converter like he did:
use converter
He uses xml configuration.
If you want to use annotations, just have a look at these two java classes in this git repository:jpa converter with annotation
Therefore you can use the annotation
#Convert(converter = JPACryptoConverter.class)
(Given that JPACryptoConverter is a child of AttributeConverter).
Well short answer is No you can't simply extend the #Column annotation in Hibernate by adding a protection option to it but to provide a complete answer you can surely combine it with other annotations, to protect/encrypt a column in Hibernate you have two possible options:
Use Hibernate's #ColumnTransformer annotation to provide a customised column transformer for your column.
Use JPA Attribute Converter to provide a custom representation of your column.
Useful links:
For further reading about these two options you can check the following Thoughts On Java's tutorials:
How to map encrypted database columns with Hibernate’s #ColumnTransformer annotation.
How to implement a JPA Attribute Converter.
You can also check this answer to see how can you implement a custom Column Transformer.
A third option is to use Jasypth Integration library with Hibernate, you can read more about it in Integrating Jasypt with Hibernate 3.x or 4.x.
This question already has answers here:
Hibernate Annotations - Which is better, field or property access?
(25 answers)
Closed 8 years ago.
I'm a JPA beginner and i'm actually trying to learn the basics of this API, my questionn is ; is there a difference between applying an annotation to a field and applying it to its getter?
I don't have a good JPA reference for it, but if you're using Hibernate there are some notes about this choice in the Hibernate Annotations reference. It says:
Depending on whether you annotate fields or methods, the access type used by Hibernate will be field or property. 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. Mixing annotations in both fields and methods should be avoided. Hibernate will guess the access type from the position of #Id or #EmbeddedId.
Hibernate uses reflection to access the values, and this choice will determine whether it calls the getters and setters or uses direct field access.
Which choice is actually better is debatable and may vary depending on whether you do work beyond the obvious getting and setting of fields in your getters and setters.
There is a difference between Field and Property access as others have stated. Field indicates direct access by the persistence provider and Property (method access) indicates the use of the getter/setter of your choosing to access the data.
I would recommend starting with Field access as in my experience this is easier/safer for new users to get started with. Property access can be very useful, and may be generally preferred by some, but it can also lead to problems if you are not careful (due to the additional behavior that getters and setters may have). So in general it is best to use Field access as a beginner unless you have a reason to use Property access.
I also recommend picking up a copy of Pro JPA 2 by Mike Keith and Merrick Schincariol if you are just getting started with JPA. It covers this and many other related topics.
I'm stuck with validation in my current use case.
My app has standard structure (WEB <-> EJB3 Services <-> EJB3 DAO <-> DB).
I have an entity which has validation annotations applied to it.
#Entity
class PhoneNumber {
...
private NumberType numberType;
}
where
enum NumberType {
FIXED,
MOBILE,
ANY
}
Now I have new validation rule to be applied. On PhoneNumber update there should be not possible to change NumberType to ANY if it was set previously to either FIXED or MOBILE.
My Bean Validation rules are checked just before db operations, and the rule above should be applied in service layer (at least I think so) to have a DB access to get previous entity version to compare.
But without having bean not yet validated I'm forced to check manually if e.g. numberType is not null.
Can you please provide me some advices or general rules how to deal with more complex busines validations (not only checking single field's values in isolation) when using Bean Validation?
I don't think Bean Validation is the right solution for implementing this kind of business logic.
Instead you could implement this check in the setNumberType() method of the PhoneNumber entity. There you have the old value at hand and compared to an implementation in the service layer there is no chance to perform an illegal state transition by circumventing (accidentally or intentionally) the service implementing the check.
Here you can find a good description of how to write a custom validator which can do "cross-field" validation.
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?
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.
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".
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<T extends Bar> {
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.
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.
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).
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.
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.
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).
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.
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 & 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.
I believe property access vs. field access is subtly different with regards to lazy initialisation.
Consider the following mappings for 2 basic beans:
<hibernate-mapping package="org.nkl.model" default-access="field">
<class name="FieldBean" table="FIELD_BEAN">
<id name="id">
<generator class="sequence" />
</id>
<property name="message" />
</class>
</hibernate-mapping>
<hibernate-mapping package="org.nkl.model" default-access="property">
<class name="PropBean" table="PROP_BEAN">
<id name="id">
<generator class="sequence" />
</id>
<property name="message" />
</class>
</hibernate-mapping>
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.
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.
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.
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.
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.
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:
<!-- hibernate -->
<hibernate-core.version>3.3.2.GA</hibernate-core.version>
<hibernate-annotations.version>3.4.0.GA</hibernate-annotations.version>
<hibernate-commons-annotations.version>3.1.0.GA</hibernate-commons-annotations.version>
<hibernate-entitymanager.version>3.4.0.GA</hibernate-entitymanager.version>
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).
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!".
I had the same question regarding accesstype in hibernate and found some answers here.
I have solved lazy initialisation and field access here Hibernate one-to-one: getId() without fetching entire object
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.
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
To make your classes cleaner, put the annotation in the field then use #Access(AccessType.PROPERTY)
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
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".