Fleshing out the Models (The java ones :P) - 2

We saw the Object world in our example was composed of People and their Pets. Certain things that I would like to point out in the code from the previous post:

1. Both objects have been provided with a database identifier although they include separate fields that can validate their uniqueness in the application.
2. The setter methods for the identifiers have been made private as the design decision is to let hibernate set and manage the Db Identifier.
3. Care has been taken to avoid using the Db managed identifier in the equals method. The reason for this can be found in the article http://community.jboss.org/wiki/EqualsAndHashCode. (In basic terms: as we are not managing it and the field is dependent on the objects existence in the database it could create a whole lot of null checks and be difficult for unique checks in Sets and Maps).
4. Care has been taken in the Pets class to avoid referencing the fields of Owner class in the toString/ hash code method. In case lazy loading is being used, this could lead to the execution of a very large number of queries simply for the purpose of toString readability. The same reason is used to avoid pet references in the Owner.toString method.
5. The Entities thus created do not have to be dumb representations of the database Records. It makes perfect sense to use the richness of Object Oriented Architecture and to provide business methods like Owner.addPet(). The entities need not be restricted to simple getter/setter methods.

Now that we have identified the properties and behavior of our Java model classes, the next step would be to look at the Relational side of the application.