Spring Framework: Petr Kalina
Spring Framework: Petr Kalina
Spring Framework: Petr Kalina
Petr Kalina
This Presentation
Bures Kalibera
Bulej
Example 1:
z Spring:
ClassPathXmlApplicationContext appContext =
new ClassPathXmlApplicationContext(
new String[] { "seminar.xml" }
);
z seminar.xml:
z the difference:
– declarative definition of references
– instantiation left on Spring
z advantages
– swap in and out different implementations of objects at will
– create different configurations for different deployment scenarios
or for testing purposes
Discussion
z Dependency Injection
– the dependencies are "injected" to the program by the framework
and can be dealt with in a declarative way
z Inversion of Control
– the program is not in control of the framework, but to the contrary,
the framework controls the program
Example 2:
The JNDI steps in..
Example 2: motivation
create initial
context
create EJB
get EJB object
object
complete perform
operation operation
Example 2: Locator pattern
CalculatorImplEJB
CalculatorClient CalculatorIface
CalculatorImplPOJO
Example 2: Locator pattern
z as an EJB
<bean id="CalculatorImpl" class="org.springframework.ejb.access.
LocalStatelessSessionProxyFactoryBean">
<property name="jndiName">
<value>calculatorBean</value>
</property>
<property name="businessInterface">
<value>exmaple.CalculatorIface</value>
</property>
</bean>
z Client code
BeanFactory bf = ( BeanFactory ) appContext;
CalculatorIface calculator = bf.getBean( "CalculatorImpl" );
Example 2: Locator pattern
z as a POJO
<bean id="calculatorImpl"
class="example.calculatorImplPOJO">
</bean>
z Advantages:
– the same as Locator, but..
z the EJB nature of the CalculatorImpl service is hidden from the client
z the configuration can be changed declaratively
z we don't need to write Locator
z Immediate impact on testing:
– we can easily swap EJB objects for stubbed objects for Unit
Testing .. (stubbed = POJO returning already stub-wrapped
responses – don't depend on container at all)
Example 2: Locator pattern
z Alert
– Spring dependency in client !!!
– ... isn't necessary, we can inject the dependencies from the
application context
<bean id="adderImpl" ..
<bean id="multiplierImpl" ..
<bean id="calculatorImpl"
class="example.calculatorImplPOJO">
<ref bean="adderImpl" />
<ref bean="multiplierImpl" />
...
</bean>
Example 3:
Datasources &
Exceptions
Example 3: motivation
z JDBC datasources..
z Imagine a classical database handling block in JDBC:
Example 3: motivation
try {
javax.sql.Datasource ds =
(javax.sql.Datasource) ctx.Lookup("myDataSource");
con = ds.getConnection();
Statement stmt = con.createStatement();
String query = "SELECT NAME,SURENAME FROM SEMINARSTUDENTS";
ResultSet rs = stmt.executeQuery( query );
while ( rs.next() ) {
String student.name = rs.getString("NAME");
String student.surename = rs.getString("SURENAME");
studentlist.add( student );
}
}
catch (SQLException ex) {
logger.error("SQL ERROR!",ex);
}
finally { con.close(); }
Example 3: more motivation
z Spring templates...
class StudentsRowMapper implements RowMapper {
public Object mapRow(ResultSet rs, int index) throws SQLException {
Student student = new Student();
student.setFirstName( rs.getString( 1) );
student.setLastName( rs.getString( 2 ) );
return student;
}
DataAccessException
z Discussion:
– swap JDBC datasources declaratively
– handle only the exceptions we want in database independent way
z Immediate impact on testing:
– swap JNDI for non-JNDI
Example 4:
Aspects
(flavor only..)
Example 4: aspects (flavor only..)
z AOP framework
– crosscutting aspects and concerns
– intercept method calls (accesses to members..) and perform
routines before or after this happens
– from outside the program
z no repetitious code
z the aspects and concerns are dealt with as aspects and concerns of
the whole application
Example 4: aspects (flavor only..)
z the flavor:
– application accesses data on remote datasource and serves them
to the client on request.
– we write the application without caching, then we want to change
this aspect and we want to have all once served data cached
– the business methods:
serveDataById( int id );
serveDataByName( string name );
serveDataBy...
Example 4: aspects (flavor only..)
Java class Spring bean
no caching..
serve*(*); DataAccessorIface
z Observation:
– there's an AOP framework in Spring
Example 5:
Transactions
(flavor only..)
Transactions (flavor..)
aspect oriented
approach to
transactions
Leftovers:
Leftovers (not even flavor..)
Model
View
(Business logic
(view utils)
and data storage)
Controller
call get commands
business call output
methods routines
summary:
What we've been through?
z against EJBs:
– testing implications – container lock-in
– heavyweight, steep learning curve
– hinder simple design
the EJBs
z for EJBs:
– scalability (clustering, distribution)
– distribution (stateless session EJBs)
– message driven scenarios (MDBs)
– no need to write complex multithreaded code
– transparent global transaction management in the container
– security services in the container
– EJBs are more or less familiar to everyone
– DB vendor independence
EJB - Observation