Section 1.4.  Injecting Dependencies with Spring

1.4. Injecting Dependencies with Spring You're almost through with the setup for Spring. It's time to download it and put it into action. In this lab, you'll replace the RentABikeAssembler object with Spring. When I started using Spring instead of J2EE, it changed my life. I got more productive. My code got easier for me to write, and easier for my customers to understand. Since it was simpler, it often executed faster. It was also infinitely easier to refactor. In fact, I wrote a book about the value of lightweight frameworks like Spring, called Better, Faster, Lighter Java (O'Reilly). 1.4.1. How do I do that? You'll first have to download Spring. Go get it at http://www.springframework.org. That will point you to sourceforge, where you'll get the best version for your platform. We used Version 1.1. You will need to add a new folder to your project, war\WEB-INF\lib, and put the Spring libraries there (everything in the \dist folder of your Spring distribution). Moving a well-designed plain-ordinary-Java-object (POJO) application to Spring is straightforward. It only takes three steps: Refactor your code to take advantage of dependency injection. Model objects are beans, and services are aspects. Usually, you'll only have beans. Remove the code that instantiates the objects and sets dependencies. Build a configuration file describing your beans and aspects. Access your code through Spring. Since our individual parts are already built to take advantage of dependency injection, moving to Spring is an easy exercise. We simply replace our assembler with a Spring version, and provide a configuration file which will go in the \war\WEB-INF folder. Example 1-9 shows the configuration file. Example 1-9. RentABike-context.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans> <bean id="rentaBike" class="ArrayListRentABike"> <property name="storeName"><value>"Bruce's Bikes"</value></property> </bean> <bean id="commandLineView" class="CommandLineView"> <property name="rentaBike"><ref bean="rentaBike"/></property> </bean> </beans> And Example 1-10 is the new assembler that replaced the old RentABikeAssembler. Example 1-10. RentABikeAssembler.java import org.springframework.context.support.ClassPathXmlApplicationContext; public class RentABikeAssembler { public static final void main(String[] args) { ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("RentABikeApp-context.xml"); CommandLineView clv = (CommandLineView)ctx.getBean("commandLineView"); clv.printAllBikes( ); } } 1.4.2. What just happened? You may be scratching your head and wondering what the big deal is all about. These tiny improvements in architecture will have profound implications throughout the lifecycle of this application. You'll see the benefits almost immediately. I won't harp on them here. Instead, let's talk about what's happening under the covers. 1.4.3. What about... ...Pico, Hive Mind, and Avalon? These are all lightweight containers. Each of them has strengths and weaknesses. Neither Avalon nor Hive Mind have the critical mass that you'll want out of a container, especially if you want services that interoperate. Right now, Spring and Pico have the most market share. People tend to use Pico if they want a standalone container, but Spring has the most comprehensive support for additional services, such as declarative transactions and a rich persistence strategy.