Re: DI = XML parser that can resolve references?
On 20.10.2007 14:29, Olli Plough wrote:
Hello,
I'm having a look into that Spring stuff and therefore into dependency
injection, of course. Now I'm wondering what's the great catch about
DI. Yes, right, you get around import statements in your code that
reference technology-specific or vendor-specific classes. This is of
course very useful. What I actually already did myself without knowing
about DI was interface-based injection which is an obvious approach I
would say that everyone would find himself. I was skimming my Spring
book from beginning to end and back again and it seems to me that DI
is not much more than that. I mean build a XML parser that can resolve
references to other objects defined in XML and you are basically done
(objects referenced must be programmed against an interface, of
course, to be decoupled).
I thought that DI was something like this:
public class MyBean
{
@PersistenceContext(name="myDB")
EntityManager em = null;
}
Now when I create an instance of MyBean the variable em is already
set.
This cannot be because before the instance exists the member does not
exist as well. The bean will have to be created before em can be set.
However it's guaranteed that it will be set at a certain point in time,
i.e., before one of the bean's business methods is invoked.
I don't have to bother how to get a reference to that thing and
am therefore decoupled from the respective JPA provider. How does em
get set now? Seems to me that this must be done when the lookup from
the JNDI-Server (InitialContext) is made. But then I have a dependency
on the JNDI-Server, I'm not really technology independent here.
Maybe someone out there could help a poor one-eyed guy out with this
and explain this to me. Maybe I'm just thinking too far and thinks are
perfect the way they are ...
The example you showed is DI - but not due to the automatic setting of
the member but due to the fact that EntityManager is an interface (IIRC)
which defines a set of operations. The class of the EM that is put
there by the JEE container will have concrete implementations of those
methods defined in EntityManager. That way MyBean can use (read "depend
on") EM according to the protocol defined by the interface without
having to know anything about the concrete JEE container's EntityManager
implementation. The dependency on the concrete EM is "injected" because
at compile time there is just the dependency on the abstract EM. HTH
Kind regards
robert
http://en.wikipedia.org/wiki/Dependency_injection