Java Reference
In-Depth Information
the caller must obviously have a reference to the object. Earlier you saw how the
repositories were passed as constructor parameters to PlaceOrderService . How-
ever, for the reasons that I describe next, it is not always possible to do this with
domain model entities. Let's explore the problem and the various solutions.
The most convenient approach is to pass the repositories to entities as con-
structor parameters in this same way that they are passed to services. This enables
the entities to be initialized using the lightweight container's constructor injec-
tion mechanism. Passing repositories as constructor parameters is a lot simpler
than passing repositories around as method parameters and does not have the
drawbacks of using singletons, as I describe a bit later. However, using this
approach to initialize entities is not straightforward because unlike services, which
are typically instantiated by the lightweight container, entities are created by the
persistence framework when it loads them from the database.
By default, a persistence framework creates objects directly using the class's
default constructor, and it's not possible to pass in any required objects. Some
(but not all) persistence frameworks have a configurable object instantiation
mechanism that allows an application to control how objects are instantiated. The
application can configure the persistence framework to create objects using a
lightweight container that injects the dependencies. For an example of using con-
structor injection with Hibernate, see http://hibernate.org/182.html [Hibernate
injection]. However, because this approach is not universally available I am not
going to use it in this topic.
Another option is to implement repositories using static methods and vari-
ables. You could, for example, implement a repository as a singleton or a Thread-
Local . This approach works with any persistence framework and does not require
the repositories to be passed around, which can sometimes make the code too
complicated. The problem with static methods and variables is that they make
code harder to test. For example, they prevent you from using an alternative
implementation such as a mock object because you cannot redirect a static
method call or variable access to a different class. They also introduce hidden
dependencies because the code depends on static variables that must be initial-
ized. Consequently, static methods and variables are best avoided.
Given that only some persistence frameworks allow you to use constructor
injection to initialize entities and that using static methods and variables has some
serious drawbacks, it often makes sense to pass repositories as method parame-
ters. It avoids the problems of using singletons and does not rely on proprietary
persistence framework features. The one drawback of adopting this approach,
however, is that it can have a ripple effect through the code. We might have to
 
 
 
 
 
Search WWH ::




Custom Search