Putting some Spring in your step

1
Putting some Spring in your step

• Incremental adoption of Spring

2
Revolutions and Evolutions

• Spring as a Revolutionary Technology?
• Maybe.
• For today, lets consider it merely as a
  collection of convenient implementations enabling
  us to evolve our programming.

3
Aside High code quality

• Testcases, community, standards, review.
• Iron fisted control of a few folks with way too
  much spare time.
• Whatever you credit, objectively this code is
  solid.

4
But what does it do?
AOP Source-level metadata AOP Infrastructure
JDBC Core, Object, Transaction
O R M
Web MVC MVC Views Supports JSP / JSTL PDF /
Excel Velocity / Struts Whatever
Web utilities
Context ApplicationContext JNDI support UI
support Mail
DAO DataAccessException
CORE Supporting Utilities, Bean Container
5
AOP

• Aspect oriented programming
• Say what???
• Dynamic proxies. Interceptors. Pointcuts.

6
Core

• Bean Factory

7
DAO

• Support for your Data Access Objects.

8
JDBC

• Takes the boilerplate out of boilerplate JDBC
  code.

9
ORM

• Object relational mapping support and abstraction

10
Context ApplicationContext

• Beyond the beans
• MessageSource
• Email sending
• Localization / Internationalization
• User interface Themes, etc.

11
Web utilities

• Remoting support

12
Spring Web MVC

• Not just any old Web MVC implementation

13
That was Spring in a whirlwind

• Theres a lot here
• But lets focus on just enough to get you to
  install it.
• You can then be pleasantly surprised to find out
  that it does all the rest too.

14
Not all the rest

• Spring only sets out to do what they think others
  have not done / not done well.
• Doesnt reimplement logging, connection pooling,
  testing, Commons projects, etc.

15
Theme Incremental Improvement

• Walk before you can run.
• Crawl before you walk.
• Drool before you crawl?
• Wherever you think you are, Spring has something
  to offer.

16
Previous Presentation

• Spring Theory
• Hollywood Principle

17
Dont call us, well call you.
Hollywood Principle
18
Practice

• What is the Hollywood Principle?

19
Dont call us, well call you.
Hollywood Principle
20
Todays content

• Spring you can reach for and use
• Dependency Injection in action
• Spring you can use without reaching
• Spring JDBC

21
Dependency Injection

• Hollywood approach to dependencies well call
  you to inject your dependencies.

22
Feels great!

• Express dependencies as Interfaces
• Write classes with fewer concrete dependencies
• Much more testable code.

23
BeanFactory

• Report from the frontlines this works.
• Works better than you might expect.

24
applicationContext.xml

• ltbean idfoo classedu.yale.Foo /gt
• ltbean idbar classedu.yale.Bargt
• ltproperty namefoogt
• ltref idfoo/gt
• lt/propertygt
• lt/beangt

25
Aside Powerful Bean declaration

• Singletons and Prototypes
• Static factories (say Ugh!)
• Instance factories
• Constructor arguments
• JavaBean Properties
• Lists, Maps, Properties, MessageBundles
• Lookups (e.g. JNDI)

26
Where does Spring put it?
Spring ContextLoaderListener
Servlet Context
Spring ApplicationContext
ltbean idfoo /gt ltbean idbar .../gt ltbean
idwombat /gt
27
How do I get it?
Servlet Context
ApplicationContext
WebApplicationContextUtils
Your Servlet
28
Poor Mans Dependency Injection

• Javas a pretty nice language
• You can write your own ContextListener to
  instantiate your interfaces.
• You can have separation of concerns, Dependency
  Injection, interface-driven development w/o Spring

29
Web MVC

• We have a lot of invested expertise in
• JSP / JSTL
• Bare Java Servlets
• Struts
• JSF?
• Whatever other web framework youve learned

30
The theme was Evolution

• Keep using existing Web-tier technologies where
  it makes sense to do so.
• Keep writing / maintaining those Servlets /
  Actions / whatevers
• Potentially, adopt ApplicationContexts as the way
  your Servlets/Actions/whatevers get access to
  instances of Business Interfaces

31
But even if you dont

• Spring we can use right now

32
Data Access Objects

• Interfaces for your data access needs
• Read information from DB, write back to DB,

33
DAOs plausibly implemented using JDBC

• Or Hibernate, or no DataSource at all, or
  whatever

34
But plausibly, JDBC

• Expertise
• Power
• Existence of / reusability of queries / stored
  procedures
• Institutional investment in Enterprise Database

35
JDBC

• Writing raw JDBC is a pain
• Its easy to forget to close resources
• Boilerplate iteration over result sets
• Boilerplate checking result set size
• Boilerplate translation to/from Java objects
• SQLException

36
Easy?

• Bold statement Spring provides exactly the JDBC
  abstraction we would have written, all things
  being ideal

37
Okay wise guy

• What is it that we would have implemented?

38
Dont call us, well call you.
Hollywood Principle
39
JDBC in Hollywood

• Threadsafe framework classes that provide
  boilerplate functionality and configuration or
  callback.
• Write once the thing that is always the same.
• Write each time exactly what you have to.

40
A SQL Query

• SELECT foo, bar FROM splat WHERE wombat ?

41
MappingSqlQuery

• public YourDaoImpl(DataSource ds)
• super(ds, SQL)
• super.declareParameter(
• new SQLParameter(name, TYPE)
• compile()

42
Implement the abstract method

• protected Object mapRow(ResultSet rs, int rowNum)
  throws SQLException
• Splat splat new Splat()
• splat.setFoo(rs.getBoolean(foo))
• splat.setBar(rs.getSomeType(bar))
• return splat

43
What you just got

• ResultSet, PreparedStatement, Connection closed
  properly.
• Detailed, vendor-specific, undeclared aka
  Runtime aka Unchecked exceptions extending
  DataAccessException.
• Logging. Of the actual SQL, if you crank up the
  logging level.

44
What you just got

• Threadsafe, reusable Java object representing
  your query

45
Same pattern for

• Stored Procedures
• Updates
• Functions
• Queries that dont map to Java objects

46
Incidentally

• Spring would love to make you a DataSource
  outside of your ServletContainer
• Spring would love to be the source for that
  DataSource you supplied your DAO implementation.

47
Template Method Design Pattern

• Spring is using this design pattern here
• The pattern is applicable elsewhere
• E.g. CAS PasswordHandler

48
Dont call us, well call you.
Hollywood Principle
49
Stored Procedure Example

• Netregs getPersonRole takes a netid, returns a
  role.

50
DAO interface

• Public interface NetregRoleDao
• public String roleForPerson(String netid)

51
Constructor

• SQLNETREG.API.getPersonRole
• public RoleStoredProc(DataSource ds)
• super(ds, SQL)
• declareParameter(new SqlOutParameter(role,
  Types.VARCHAR)
• compile()

52
DAO interface implementation

• public String roleForPerson(String netid)
• Map params new HashMap()
• params.put(netid, netid)
• Map results execute(params)
• return (String) results.get(role)

53
You can use this today

• The creative work is writing the query and the
  translation from the Row to the fulfillment of
  the DAO interface.
• The boilerplate is done for you.

54
And now that youve installed it

• Check out what else Spring offers.