
Dan Allen
(4300) It's evolution, baby! Bijection deplaces dependency injection
Technical short talk 20 min
Thursday, 2008-06-26, 11:30 - 11:50, Arena 5
Dan Allen - TetraTech, Inc. | Manning | JBoss Committer (speaker)
Topics
Abstract
Dependency injection, by far the most popular adaptation of the Inversion of
Control (IoC) principle, has been the driving factor of POJO-based development
for many years. But, for as much as dependency injection has been studied,
discussed, and presented, no significant improvements have been made to its
design since its emergence. That is, until now. This session introduces
bijection as an evolutionary development of dependency injection. Bijection
forms the basis of the IoC container in JBoss Seam.
Classic dependency injection has two major limitations that render it inadequate
for use in stateful applications. Its biggest downfall is that it is static.
Dependency injection allows the factory pattern to be realized without requiring
the developer to write boilerplate code. The dependencies of an object are
established once, at creation time. From that point forward, the object is stuck
with the dependencies it is handed. If the primary object and its dependencies
are singletons, or otherwise stored in the same scope, then the covalent bonding
between objects does not present a problem. However, when related objects do not
share the same duration, which is often the case in stateful applications, a
predicament known as "scope impedance" can arise. Scope impedance
occurs when an object from a narrower-scope is injected into an object in a
wider-scope. As a consequence, the narrower-scoped object winds up outliving its
intended lifetime, potentially leading to undefined or dangerous behavior.
The second shortcoming of dependency injection is that it only allows objects to
consume dependent objects. As the name suggestions, its purpose is to inject
dependencies into an object. This one-sidedness breeds selfish objects. The
objects just take, take, take, without ever contributing anything back to the
container. In reality, the objects do give back. It's just that the process of
contributing does not benefit from the loose-coupling that characterizes the
inversion of control principle. For example, web-controllers may interact
directly with the Servlet API to store objects in request attributes to allow
them to be used by the view. This direct access of the Servlet API diminishes
the "POJO rating" of the object.
This session will demonstrate how bijection corrects both of these deficiencies.
Bijection, implemented as an AOP method interceptor, traps method calls to the
objects on which it is installed and (re)establishes the object's dependencies
before allowing the target method to proceed. Since the dependency injection
instrumented by bijection happens at invocation time, rather than at creation
time, like with classic dependency injection, it makes the relationships between
objects dynamic. The dependencies are continually updated as the object is used.
This style of dependency injection makes it safe to allow objects in any scope
to interact with each other without fear that the relationship will permit a
narrower-scoped object to live past its expiration date.
The new territory that will be embarked on in this session is the topic of
outjection. The bijection interceptor triggers outjection in the post method
invocation logic. Outjection is a term coined by the Seam developers to denote
the flip-side of injection. The prefix "out" indicates that the values
of designated properties, not necessary the ones subject to injection, are
contributed back to the container, manifesting themselves as context variables.
Each method call produces container-managed objects as well as consume them. As
a final step, properties that receive injections are nullified before the books
are closed on the method call.
After this session, attendees will understand how bijection works, why it is
important in a stateful design, how it provides transparent access to Servlet
API scopes, and recognize it as an evolution of the dependency injection
pattern, for which Seam serves as the reference implementation.






