I finished a project using the Spring Framework and all I can say is sweet. I’m impressed by both the simplicity as well as the flexibility and it is well known that I’ve in love with the design philosophy the spawned it.

But I thought that I would give you my favorite features/aspects, and no, I’m not going to mention transparency or inversion of control or any of the bullet items you’ll find on their web site. This is the list of the understated features…

Introduction

While Spring is a “web framework,” allow me to concentrate (in this article at least) on its “core framework.” There shouldn’t be any reason why the core can’t be taken to other worlds, but the developers have definitely concentrated on the “web” aspect. Which is good for me, since that is what I’m doing most of the time.

The “core” of the Spring Framework is like those hardware breadboards that allows you to plug in software components. Once the components are in place, you configure them by setting properties, and then wire them together. The entire breadboard receives inputs/events and then, in turn, calls particular components.

The wiring is pretty obvious. Each component is given a name, and if a component has a property that matches a component’s type, you can wire them together. I guess an example will make that clear:

<bean id="myBean" class="org.howardism.myBean">  
  <property name="aValue">  
    <value>messages</value>  
  </property>  
  <property name="connBean">  
    <ref bean="connectionBean"/>  
  </property>  
</bean>

<bean id="connectionBean" class="myConnectionBean" />

When the myBean component is instantiated, the container will realize that it needs the connectionBean component as well. So once the connectionBean is instantiated, it will call myBean.setConnBean() method.

The container (what I’m calling a breadboard”) understands all of your favorite primitives as well as the basic collection types. For instance, if your component accepts a java.util.List, you can create a list on the breadboard, like:

<bean id="menu1" class="ordermenu.Menu1Controller">  
  <property name="menu">  
    <list>  
      <ref bean="appetizers"/>  
      <ref bean="soup"/>  
      <ref bean="salad"/>  
      <ref bean="stirfried"/>  
      <ref bean="curries"/>  
      <ref bean="seafood"/>  
    </list>  
  </property>  
</bean>

It is pretty straightforward, and the container itself behaves and is configured just like your own application, making the entire experience consistent. That's the core. Now let me wax poetic on some of the features that I've come to love. (I'd also recommend reading Introducing the Spring Framework by primary author of Spring, Rod Johnson).

Application Configuration

Any good application will have remove as much of the hard-coded values out of the application and into a runtime configuration file. While the performance may not be optimal, you gain a lot in flexibility without having to recompile. We've all been in that situation where a program is acting strangely in the field, but in order to get more logging information, you had to first recompile and redeploy the application.

The biggest downside of adding runtime configuration features is the development time. But there is also the potential problem associated with every module and component implementing their own configuration. As you can tell by my little overview, runtime configuration is built into the system just by using Spring.

Instead of having the following code:

SmtpMailer mailbean = new SmtpMailer();

mailbean.setTo("....");
mailbean.setCC("....");
mailbean.setBCC("....");
mailbean.setSubject("....");
mailbean.setFrom("....");
...

You replace it with a getter/setter methods:

SmtpMailer mailbean;

public void setMailer (SmtpMailer b)    {
    mailbean = b;
}

Then in your Spring breadboard, you will set up an SmtpMailer component, and do all the configuration of it, and then hand it to the code that will use its services. So, in this example, if I needed to change the subject, I could alter the Spring XML file instead of editing, recompiling and redeploying my application.

Facilitates Components

If you’ve spent any time at all with me, you would have already had an earful on my views of using components and CBD. Spring makes it incredibly beneficial to build your application with components. Each component can be built and tested independently, and the Spring Framework allows you to easily hook them together.

In a previous discussion, I talked about the advantages associated with loosely coupling your components by using interfaces. Instead of mentioning a class directly in your code, you refer to an interface the class implements. Easier to change implementations. However, if your code instantiated an object like this:

MailerInterface mailbean = new SmtpMailer();

Then you can replace the implementation of the interface with a different class fairly easily. However, you still have to edit and recompile your code… but not with Spring. Your getter/setter methods could deal only with interfaces, and you can specify which implementing class at runtime.

Pick and Choose yer Features

The entire Spring Framework is nicely abstracted into layers, so while the framework has grown considerably, you don’t have to use anything you don’t want to. You can pick and choose.

In wanting to build a project with Spring, I purposely chose something particularly small in scope. However, since Spring’s documentation has not matured yet, I was having a problem that I couldn’t figure out how to do the “Spring-way”. So I didn’t. I just coded it up like I would normally have done, and away I went. It was really refreshing not to beat my head against poor documentation and source code.

Spring vs. Struts?

Spring doesn’t compete against Struts … at least, not directly. You can use Struts for your front-end and have Spring hold your model. However, Spring can stand on Struts’ shoulders and has implemented the front-end, and in the process, solved some of Struts’ thorny bits.

My biggest complaint with Struts is its tight coupling with JSPs, and Spring allows support for JSP, Velocity and FreeMarker right out of the box. Now I can create controllers and even form validating beans without the need for complicated, difficult-to-maintain JSP code.

I’ve also noticed that a lot of people have been porting their Struts application over to Spring (see these comments), and it sounds like it is fairly easy.

Conclusion

I really quite enjoyed building this project in Spring, but the real test came when my client came back with some minor changes. I made all of the changes in either the database or the configuration file and didn’t even touch my code.

Also, every component and controller was unit tested. Doing the same thing in a full app server and Struts would be quite difficult if not impossible.

So, yeah, I highly recommend it.