Java Reference
In-Depth Information
don't fit particularly well with this model. By definition, entity classes aren't interfaces,
and they do contain a reasonable level of mapping metadata. When working out how
best to deal with your
JPA
entities, you have two main options, which we'll discuss next.
EXPOSING ENTITY CLASSES
The simplest option is to bite the bullet and export the
JPA
entity classes. This has the
important, and sometimes unwanted, effect of making your entity classes part of your
API
. Exposing the entity classes directly makes it quick and easy for clients to use
them, and also allows other bundles to make use of your persistence units by directly
using your
EntityManagerFactory
services. This works well if the entity classes are
simple, JavaBeans-style objects with getters and setters. It's also important that the
entity classes offer a reasonably stable
API
, and particularly one that isn't specific to
the underlying database implementation.
The main problems with exposing entity classes stem from the fact that the entities
have become part of your
API
. First, you can no longer replace your persistence bun-
dle without having to refresh all your persistence clients. Second, and probably more
awkward, you can no longer make structural database changes, or add new features to
your entity classes without potentially breaking the rest of your application. The more
complex the logic in your entity classes is, the more likely this is to happen. Finally, if
you do expose your entity classes, then you're implicitly accepting the fact that other
bundles can directly use your persistence units without going through a data access
layer. If your database model is complex, or you wish to enforce some rules about valid
data values, this is often a deal breaker.
HIDING ENTITY CLASSES WITH INTERFACES
Normally, there's no reason for any code to have a direct dependency on the persis-
tence bundle, a fact that helps makes the persistence bundle easy to upgrade. If you
add a data access service to your persistence bundle, you can use this to load and store
objects but only refer to them by interface. This is exactly what you do in the Fancy
Foods application, where
Inventory
and
Accounting
from section 3.2.4 take inter-
faces instead of implementations. Not only does this keep your business layer loosely
coupled to your persistence bundle, but this has the big advantage that you can force
every
bundle to use your data access methods. This means that you can enforce rules
about minimum stock and credit levels much more easily.
There are clear advantages to using interfaces to hide your entity classes; however,
it isn't a perfect solution. It's easy for the data access service to return data objects that
have been looked up—either the entity types will implement the interface directly, or
there can be a wrapper class. Storing or updating the entity instances in
JPA
requires
instances of the entity class. This means that the data access service must be able to
create new instances of the entity classes from raw data (or other implementations of
the interface) that get passed in. Sometimes you might get lucky, and find that you
can cast the instance you were passed to an entity implementation (if, say, it came
from a previous lookup), but other cases can involve significant amounts of copying.
