(spring)
The big advantage over the application servers is with SPRING, your classes do not need to implement any interface to be supported by the framework (as opposed to J2EE application servers and EJBs ) . It is in this sense that SPRING is called "light" container.
(spring)
Besides this kind of super object factory , SPRING provides a range of abstractions to manage include:
The transactional
The EJB call
Creating EJBs
Persistent objects
Creating a Web interface
The call and the creation of WebServices
To achieve this, SPRING will support the principles of design pattern and IoC AOP (PDO) .
(spring)
II . Why you need SPRING? The IoC pattern ▲
(spring)
The heart of SPRING and what makes it great strength is the implementation of the design pattern " Inversion Of Control " or " Dependency Injection " described by Martin Fowler ( http://www.martinfowler.com/articles/injection . html) . For an overview of the design pattern in French on our website at this address http://smeric.developpez.com/java/uml/avalon/ioc/ , so I content myself with a brief description in this article.
(spring)
II -A. The IoC pattern ▲
(spring)
The idea of IoC pattern is very simple, it is , when an object A needs a B object to delegate to a C object linking of A and B. Ok, it looks like an old algebra equation incomprehensible while a small sample code is better than formula smoker.
(spring)
Take the example of a traditional code where a class needs its factory to manage access to the database. The code is fairly standard , knowing that an effort has been made to centralize the creation of different fabrics in a general manufacturing .
(spring)
Select
Product
product package ;
import factory.DAOFactory ;
import product.dao.ProductDAO ;
public class Product {
private ProductDao dao ;
private long id;
private String name ;
private String description;
public Product () {
dao = ( ProductDao ) DAOFactory.getFactory ( " ProductDao ");
}
public String getName () { return name ;}
/ / etc.
}
Select
DAOFactory
factory package ;
import product.dao.ProductDAOImpl ;
import product.dao.ClientDAOImpl ;
import product.dao.CommandDAOImpl ;
import java.util . * ;
{ public class DAOFactory
private Hashtable factories ;
private static DAOFactory self = null;
protected DAOFactory () {
factories = new Hashtable ();
factories.put ( " ProductDao " ProductDAOImpl new ());
factories.put ( " ClientDAO " ClientDAOImpl new ());
factories.put ( " CommandDAO " CommandDAOImpl new ());
}
public static Object GetFactory (String factoryName ) throws NullPointerException {
DAOFactory.self return () get ( factoryName ) . ;
}
protected Object get ( String factoryName ) throws NullPointerException {
return factories.get ( factoryName ) ;
}
public static synchronized DAOFactory self () {
if ( self == null) {
DAOFactory self = new ();
}
return inductor;
}
}
What simple observations can be made about this design?
(spring)
The code depends on an appeal to the class DAOFactory
Different DAO implementations are declared in the class hard DAOFactory
But then , what problems it poses on?
(spring)
Pb1 - How the test when implementing the DAO classes are not yet developed?
Pb2 - How to make the application to work with different DAO classes in different contexts ( context centralized server , distributed context , context " test phase " context "production" ) ?
Solution to Problem 1
(spring)
The solution here is to change the code DAOFactory class ok . But how to share the modified code while many developers do not have the same requirements in terms of creation of factories ?
Can also accept having to change the code works when switching to different test phases ?
(spring)
Solution to Problem 2
(spring)
The case presented is simple but imagine that some DAO classes are classes distributed , deployed in an application server. The creation of these classes should be done via a JNDI request. Ok , so you can modify the code DAOFactory class for these classes in particular. So how do the test when these classes are not yet developed? And in general , can not we find it simpler and consumes less time to achieve out of context testing an application server and then replace during the tests, XXXDAOImpl class by conventional Java classes ( the " mocked " objects, plugs in the french text) ?
(spring)
With SPRING, all these problems are outsourced and managed by the framework . So just write the following code :
(spring)
Select
Product
product package ;
import factory.DAOFactory ;
import product.dao.ProductDAO ;
public class Product {
private ProductDao dao ;
private long id;
private String name ;
private String description;
public void setProductDAO ( ProductDao dao ) {
this.dao = dao ;
}
public String getName () { return name ;}
/ / etc.
}
We see here that our Product class is independent of any manufacturer and it does state that a " setter " for his " dao " property .
(spring)
The framework SPRING, via the following configuration file , supports the linking of different objects :
(spring)
Select
<beans>
<bean id="productDAO" class="product.dao.ProductDAOImpl"> </ bean>
<bean class="product.Product">
<property name="productDAO">
<ref bean="productDAO"/>
< / property>
</ bean>
</ beans >
(spring)
To address the issues raised above, it is sufficient to handle specific configuration files for testing and a specific configuration file to the start of production of the application ( each reporting XXXDAOImpl adapted to the context).
(spring)
That objects are created with a simple " new " or by searching in a JNDI directory , which can be the case for EJB components , has no impact on the application code .
(spring)
You will understand better after reading the chapter on EJBs , but SPRING, it is possible to create an application code that manipulates traditional Java classes ( POJOs that is called : Plain Old Java Objects) without have to master all the technical aspects of the technology that you implement , SPRING is responsible for the technical " clue ".
0 commentaires:
Enregistrer un commentaire