> However spring does this HEAVY lifting for you in possibly the most eloquent way i could think of...Could you give an example of what kind of lifting it does for you? That would be helpful to me in figuring out why to use it.
As it happens, here's one I prepared earlier :-)
<p />
Say you have a POJO containing some JDBC code & it's deployed within a J2EE app. Let's say this
needs a DataSource. This might look something like:
public class MyDAOImpl implements MyDAO {
private static final Logger LOG = Logger.getLogger(MyDAOImpl.class);
private DataSource _myDataSource;
public MyDAOImpl() {
InitialContext ctx = null;
try {
ctx = new InitialContext();
_myDataSource = (DataSource)ctx.lookup("MyDataSource");
}
catch (NamingException e) {
throw new SystemException("Error looking up datasource from JNDI", e);
}
finally {
if (ctx != null) {
try {
ctx.close();
}
catch (NamingException e) {
LOG.warn("Error closing JNDI naming context", e);
}
}
}
}
...data access methods...
}
With Spring, you can get rid of all the lookup stuff with the following bean configuration XML fragment:
<!-- JNDI connection template.
Configures a JndiTemplate object (part of the Spring Framework) which provides JNDI
lookup capabilities against a particular JNDI server.
-->
<bean id="myJNDITemplate" class="org.springframework.jndi.JndiTemplate"/>
<!-- Datasource.
Uses an object from the Spring framework to lookup a DataSource from a JNDI server.
The datasource is then available as a Spring bean with the specified id.
-->
<bean id="myDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiTemplate">
<ref bean="myJNDITemplate"/>
</property>
<property name="jndiName">
<value>MyDataSource</value>
</property>
</bean>
<!--
Creates a DAO bean which uses the datasource configured above.
-->
<bean id="myDAO" class="uk.co.myorg.myapp.dao.jdbc.MyDAOImpl">
<property name="dataSource">
<ref bean="myDataSource"/>
</property>
</bean>
You would remove the lookup code from the constructor of MyDAOImpl and add a setter method:
public void setDataSource(DataSource dataSource) {
_myDataSource = dataSource;
}
At runtime, the configuration XML is used to configure a Spring bean factory. This creates the
POJOs which back the above bean definitions and wires them together according to the bean references.
Your application code can then get the DAO object by just doing:
BeanFactory beanFactory = ...Load the bean factory - there are various ways to do this - see Spring docs...
MyDAO dao = (MyDAO)beanFactory.getBean("myDAO");
Note that the final Java code just looks up a single object from Spring. It doesn't need to obtain
a JNDI context or look up the DataSource. So your code becomes much cleaner. Also, we have
externalised the details of the look up process - we could change the JNDI name of the DataSource,
JNDI connection settings or even the mechanism used to obtain the DataSource just by changing the
config file.
In practice, there's no need to stop with the DAOs. You might define a layer of POJO service objects
which receive DAO references through dependency injection, all configured in the XML file. This allows you to pass in mock DAO
implementations when you unit test your service layer. It gets better too - you can use Spring bean
definitions in the XML to transparently declare transaction demarcation on your service object methods (similar
to CMT with EJB, but with less config and no tie-in to a specific API.) There's loads of other good stuff too,
such as the ORM implementations.
I've been using Spring for a couple of years now. I always try to use it on all except the simplest of apps.
The benefits of Spring grow as your app increases in complexity.
Hope this helps, <br/>
Regards,<br/>
Alastair.
