I am planning a series of posts that walk a reader through building a simplistic application using Ext-GWT as the choice of technology for the user interface, Hibernate as the ORM, HSQLDB as the backend, and the Spring Framework to manage all of the application objects and bring everything together. I've chosen these technologies, but they are not the only options. They are all open source/freely available.
What is the Spring Framework?
The Spring Framework is a modularized framework that makes working with Java EE APIs easier. Spring also provides a component container that is independent of any Java EE application server. This means you can run your applications (and test them) without being tied to any vendor-specific application servers, but enjoy enterprise-level services such as declarative transactions, internationalization, and resource handling. At its core, Spring provides a dependency injection container that allows your application objects to be wired up at run time instead of hardcoding dependencies at compile time. A simple example of dependency injection:
public class Foo {
private Bar operation;
public Foo(){
operation = new Bar();
}
public void doFoo() {
operation.doOperation();
}
}
As you can see, the class Foo depends on class Bar. What if we wanted to change the behavior of Foo's dependency on Bar? We would have to replace the Bar member with a Bar2 member, and replace the call to "new Bar()" in the constructor with "new Bar2()". What if, however, Bar was an interface, and classes that implemented Bar were injected into Foo? Foo would have no idea what Bar's implementation is (wouldn't have to explicitly call "new Bar()), and it wouldn't even know where it came from. All Foo would know is that it has a dependency on Bar and uses it. Example:
public class Foo {
private BarInterface operation;
public void doFoo() {
operation.doOperation();
}
public void setOperation(BarInterface op){
this.operation = op;
}
}
Now all you have to do is inject the appropriate implementation of BarInterface into Foo, and Foo will run as desired. The Spring Framework handles this type of "wiring up" of the components in a declarative fashion.
Why would you want to externalize "wiring up" your application components to a framework? Well, first, think of the "wiring up" of your application as "assembling the components together so that it can run." The application, once it's assembled and running, is a very different concern than the configuring and assemebling that went into it. For example, assembling the desk you just bought from a furniture store is a completely different concern than actually using it to store pencils and papers once you've completed assembly. Identifying and separating concerns like this helps to modularize and decouple the application into manageable and maintainable pieces.
Second, Spring does a good job of getting out of the way and not requiring the user to depend on the framework. In other words, your application objects do not need to use any org.springframework.* classes if they do not want (or need) to. Spring will allow your application objects to be completely unaware of the dependency injection container.
Our example
For our example, we'll modify the reference "Mail" program that ships with Ext-GWT, and give it the functionality of creating, reading, updating, and deleting (CRUD) emails from the ficticous "mail system" that we'll implement.
Before continuing, however, I highly recommend the reader download and play around with the Spring Framework. There are great tutorials online, and the reference manual is excellent too.