DI = XML parser that can resolve references?

[Olli Plough]

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. 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 ...

Thanks, Olli

 

[Robert Klemme]

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

 

[Lew]

I thought that DI was something like this:
public class MyBean
{
@PersistenceContext(name="myDB")
EntityManager em = null;
}

I have never seen an example of this annotation that uses it in collision with
an explicit initialization of the EntityManager object.

Now when I create an instance of MyBean the variable em is already
set. 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.

You aren't, the program isn't as a whole, but the part where you have the
annotation is.

The annotation is a shorthand for a mess of code that allows the container to
inject the realization of the abstraction.

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 ...

Neither thoughts nor things are perfect the way they are, which makes them
perfect just the way they are.

 

[Owen Jacobson]

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).

public class MyBean
{
@PersistenceContext(name="myDB")
EntityManager em = null;

}

Now when I create an instance of MyBean the variable em is already
set. 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.

In a lot of older code (particularly J2EE code), if MyBean needed
(depended on having) an EntityManager, it would create one itself.
Dependency injection is the notion that some external environment will
provide the dependencies, rather than requiring each object to manage
its own directly. That's all. Every DI framework (EJB3, Spring,
various others) is merely an abstraction for making the exact objects
provided as dependencies configurable somehow.

By providing dependencies externally, you can reduce the
responsibilities of objects from "do X, and also manage my
dependencies" to "do X". This tends to make the code more flexible
and easier to test automatically, since you can provide alternate
implementations of various dependencies and rearrange them as needed
without having to rewrite all of the "and also manage my dependencies"
code.

Though I've never heard of anyone doing it, you could write a complete
DI framework using properties files or YAML or some other text, or
even just using Java and hardcoding the dependencies one level up from
the objects that need them. There's nothing specific to XML in the
concept.

 

[Lew]

Though I've never heard of anyone doing it, you could write a complete
DI framework using properties files or YAML or some other text, or
even just using Java and hardcoding the dependencies one level up from
the objects that need them. There's nothing specific to XML in the
concept.

I've written data-access layers that used DI to retrieve, say, database
connection parameters from the deployment descriptor or a property file,
though now I'm moving to using the JPA. Come to think of it, the whole
"Class.forName( jdbcDriver )" idiom uses aspects of DI and always has.