Creating entity rules

Question

I would like to know the answer to this simple question.

When I create an entity object and I want to limit the attribute parameter (for example, I do not want to let anyone set an integer value less than 1 per attribute), should it be implemented in the installer of this attribute or should I check this restriction last in the class that processes these objects? Generally, can I use getters and setters, but I want my returners and setters to return attributes?

I know that in java there are some rules (code conventions), so I do not want to interrupt them.

Thanks in advance, I hope that my question is clear enough and sorry for any grammatical errors I could make: /.

Answer 1

Yes, recipients / setters are useful for this.

, eg:

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 Bean Validators for this.

 public class Person{ @Min(value = 0) @Max(value = 99) private Integer age; //some other code } 

Answer 2

My preferred approach is to use JSR 303 (Bean Validation API) to make sure class properties are valid.

It is perfectly good to perform validation on setters, but this is not always desirable. There is the potential of mixing the needs of several contexts that are not related to each other. For example, some of your properties should never be set from the user interface and will instead be computed by the service before they are saved. In this case, it is undesirable to have this logic inside the setter, since you need to know the context in which the setter is called; you will need to apply different rules in your user interface layer and in your persistence level. JSR 303 allows you to separate these issues with validation groups so that your user interface validation group is different from your persistence verification group.

In JPA 2.0, when you comment on your class using constraints that are evaluated using JSR 303 validation, the persistence provider can automatically evaluate those constraints on PrePersist , PreUpdate and PreRemove (typically not executed; below) object life cycle events. To perform entity validation in your JPA provider, you must specify either the validation-mode element or the javax.persistence.validation.mode property in your persistence.xml file; values ​​must be either AUTO (default) or CALLBACK (not NONE ).

Having a Bean validation provider is sufficient to ensure that validation is performed on JPA object life cycle events, since the default value is AUTO . You get this by default on the Java EE 6 application server; Glassfish uses the RI JSR 303 implementation, which is the Hibernate Validator, and it works great with EclipseLink.

CALLBACK mode allows you to override the validation groups that will be applied when events in the life cycle are triggered. By default, the checked default Bean group ( Default ) will be checked to update and save events; The remove event does not require any validation. CALLBACK mode allows you to specify a different verification group for these events using the javax.persistence.validation.group.pre-persist , javax.persistence.validation.group.pre-update and javax.persistence.validation.group.pre-remove .

Keep in mind that JSR 303 validation can be used outside the Java EE container, although the link to the Bean API documentation I posted above is from the Java EE 6 API documentation.

Answer 3

This is the goal of getters and setters.

If we cannot add any behavior to these methods, well ... why don't we use public attributes?

Answer 4

From my understanding of your question, this is pretty much related to the principle of encapsulating OO. You can take a look at this article: http://www.tutorialspoint.com/java/java_encapsulation.htm

Answer 5

Getters and seters are great for adding constraints, just like Jigar Joshi has in his answer. This way you get feedback immediately and can handle the problem when it is submitted.

Another solution would be to use object validation (something like the JSR-303 implementation), which allows you to annotate a field with minimum and maximum values. Sort of

 @Min(value=1) private int myvalue; 

Then you can check the entire object at a time and get all messages if you have other restricted fields. This is obviously not always useful, but if it suits you, this is an option.

Finally, when you say “entity,” I think of something stored in a database or related to ORM tools. If so, you need to be careful what you do in your getter. For example, if you are doing lazy initialization in a getter, some ORM providers will mark the object as dirty and try to dump it into the database, which may lead to an unintentional write.