Property-based unidirectional one-to-one relationship in Java

Making ECC200 in Java Property-based unidirectional one-to-one relationship

@Entity public class User { private Long userId; private String email; private BillingInfo billing; One-to-one relationship ... using properties @OneToOne public BillingInfo getBilling() { this.billing; } public void setBilling(BillingInfo billing) { this.billing = billing; } } @Entity public class BillingInfo { private Long billingId; private String creditCardType; ... }

The optional element tells the persistence provider if the related object must always be present. By default, this is set to true, which means that a corresponding related object need not exist for the entity to exist. In our case, not every user always has billing information (for example if the user just signed up), so the relationship is optional and the billing field can sometimes be null. If the optional parameter is set to false, the entity cannot exist if the relationship or association does not hold. In other words, no User without BillingInfo could ever exist. You ll see the mappedBy parameter in action in the next section when we discuss bidirectional associations. Bidirectional one-to-one The real point of having domain relationships between entities is to be able to reach one entity from another. In our previous example, we can easily reach the billing information through the billingInfo reference when we have an instance of a User. In some cases, you need to be able to access related entities from either side of the relationship (admittedly, this is rare for one-to-one relationships). For example, the ActionBazaar application may periodically check for credit card expiration dates and notify users of imminently expiring credit cards. As a result, the application should be able to access user information from a given BillingInfo entity and the User-BillingInfo relationship should really be bidirectional. In effect, bidirectional one-to-one relationships are implemented using two @OneToOne annotations pointing to each other on either side of the bidirectional relationship. Let s see how this works in listing 7.7 by refactoring the code from listing 7.5.

@Entity public class User { @Id protected String userId; protected String email; @OneToOne protected BillingInfo billingInfo; } @Entity public class BillingInfo { @Id protected Long billingId; protected String creditCardType; ..

protected String routingNumber; @OneToOne(mappedBy="billingInfo", optional="false"); protected User user; }

In listing 7.7, the User class still has a relationship to the BillingInfo class through the billingInfo variable b. However, in this case the relationship is bidirectional because the BillingInfo class also has a reference to the User class through the user field C. The @OneToOne annotation on the user field has two more interesting things going on. The first is the mappedBy="billingInfo" specification C. This tells the container that the owning side of the relationship exists in the User class s billingInfo instance variable. The concept of a relationship owner doesn t originate from domain modeling. It exists as a convenience to define the database mapping for a relationship only once instead of repeating the same mapping for both directions of a relationship. You ll see this concept in action in chapter 8 when we describe O/R mapping. For now, simply note the role of the mappedBy attribute. The second interesting feature of the @OneToOne annotation on the user field is that the optional parameter is set to false this time. This means that a BillingInfo object cannot exist without a related User object. After all, why bother storing credit card or bank account information that is not related to an existing user

7.3.2 @OneToMany and @ManyToOne As you might have gathered from the ActionBazaar domain model in figure 7.3, one-to-many and many-to-one relationships are the most common in enterprise systems. In this type of relationship, one entity will have two or more references of another. In the Java world, this usually means that an entity has a collection-type field such as java.util.Set or java.util.List storing multiple instances of another entity. Also, if the association between two entities is bidirectional, one side of the association is one-to-many and the opposite side of the association is many-to-one. In figure 7.6, the relationship between Bid and Item is one-to-many from the perspective of the Item object, while it is many-to-one from the perspective of

Figure 7.6 Every Item has one or more Bids where more than one Bid may be placed on an Item. Therefore, the relationship between Item and Bid is one-to-many whereas the relationship between Bid and Item is many-to-one.