Data Modeling
A final couple of words on entity beans are merited before moving on. The Office bean has remained very simple so far, allowing you to overlook a few problems related to dealing with entity beans in a large application. This simplicity exists for two reasons: first, the bean stands on its own, and second, it is a frequently changed object. These two facts are discussed in the following sections.
Independent and Dependent Data Objects
The fact that an office is a complete
entity
means that it is an independent data
object. In other words, a Forethought office does not depend on any
other data to be complete. Additionally, an office has meaning on its
own. A states table, for example, might not have this quality; for
our purposes, a state’s name and abbreviation are
not really useful on their own, and the state has purpose only within
the context of another entity that references the states table. In
this case, you would want the client to deal with the overall office
entity, perhaps setting its name, and the bean would then use the
states bean to work with that entity. In that way, the states entity
becomes a dependent object
. On the other hand,
the office entity is an independent object
.
It is also important to understand that just because an entity is used by another entity, it is not necessarily dependent. The office entity is again a perfect example: it is referenced by the users entity, specifying the office the user works in. But the office entity is not dependent, ...
Get Building Java Enterprise Applications now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.