The Spring Framework is a leading full-stack Java/J2EE application framework. It is aimed primarily at Java projects and delivers significant benefits such as reducing development effort and costs while providing facilities to improve test coverage and quality.
Spring provides a framework that encourages applications to be built in particular ways. A strong emphasis is to avoid particular styles of development or program designs that can cause grief in the Java world. Groovy as a language can also be used to overcome certain weaknesses in Java. You might argue then that Spring is less critical in the Groovy world. Perhaps this is true, but Spring provides many benefits and Groovy makes it easy to leverage those benefits when we want to. In particular, in mixed Java/Groovy environments, Groovy lets you mix dynamic typing with strong-typing as required. If you already have defined domain objects or services within your Spring wiring, you can immediately start using those within your Groovy scripts and code.
Let's start by exploring a simple calculator application.
Bare Bones Approach
Suppose we have the following implementation class:
We can make use of that class from a script as follows:
This script relies on no external wiring files. Everything is configured in the script itself. If we wish to alter our system at a later time, we simply alter the configuration inside the
Classical Spring Approach
Probably the most common way to use Spring is to use an XML wiring file. As systems grow larger, wiring files allow configuration to be centralised in easy to change 'groupings' of beans. Let's assume our calculator needs to eventually be expanded to have additional functionality. An approach to handling complexity as the system grows is to delegate functionality off to other components. Here is how we might code up an adder component:
Then, applying the delegate design pattern we mentioned earlier would result in the following refactored calculator:
To capture our software system configuration, we will use an XML wiring file (we have two beans):
Now, our script code looks like:
If we wish, we can remove the need for an XML file by using annotations. Note that we need to think carefully before using this approach extensively in a large system for two reasons. Firstly, we are more tightly coupling our system to Spring. Secondly, we are associating configuration and deployment information with our source code. Perhaps separating those concerns will have enormous benefits for large systems. The good news is that Spring lets you take on board just those annotations that you are happy to use.
Here is how we might code up our adder component:
Here is our modified calculator:
And here is our script code (note no XML file is required):