Allen Gilliland wrote:
I believe the relevant example is a case where someone looks up a bean
> directly rather than working through an interface or other class. In
> our current implementation we expect that everyone uses
> Roller.getXXXManager() to get access to a manager class by working
> through an interface. Using Spring someone could bypass using the
> Roller interface by simply calling ctx.getBean("userManager").
>
> Again, I'm not sure if this is really a problem, but it seems reasonably
> important to me.
Normally, following the dependency injection pattern, a bean would have
a private field with the interface type (e.g. UserManager) and a setter
setUserManager(UserManager userManager) that would get called at
initialization by the BeanFactory. Properly written, the bean never
knows the implementation type. It also doesn't know how to find an
instance. It just has it set by some outside entity, which is generally
the BeanFactory but could be something else that instantiates and
configures it.
Any use of ctx.getBean("userManager") is a deviation from the
dependency injection pattern back to the "service locator" pattern. It
breaks the pattern in two ways. It uses an explicit service lookup and
it makes the bean context-aware. Hence it would always be a bit suspect
and one should have to justify any such pattern deviations with
legitimate reasons (which there may be cases). Any occurrences should
raise eyebrows, concerns, and requests to rewrite the offending code in
the same way as seeing, say, new HibernateUserManagerImpl(...) (aack!)
in someone's code today --okay maybe not that strong of a no-no, but
leaning in that same direction.
--a.
