| home / programming / spring / 2 |    [previous][next] |
|
|
|
Spring is not the only lightweight container available. In the last few years, more and more Java developers have been seeking an alternative to EJB. As a result, several lightweight containers have been developed with different methods for achieving inversion of control.
Table 1.2 lists the types of IoC. These were first described with the nondescript “Type X” convention, but have since shifted to more meaningful names. We will always refer to them by the name.
Although the focus of this book is on Spring, it may be interesting to see how these other containers stack up to Spring. Let’s take a quick look at some of the other lightweight containers, starting with PicoContainer.
PicoContainer is a minimal lightweight container that provides IoC in the form of constructor and setter injection (although it favors constructor injection). We use the word minimal to describe PicoContainer because, with it small size (~50k), it has a sparse API. PicoContainer provides the bare essentials to create an IoC container and expects to be extended by other subprojects and applications. By itself, you can only assemble components programmatically through PicoContainer’s API. Since this would be a cumbersome approach for anything but the most trivial applications, there is a subproject named NanoContainer that provides support for configuring PicoContainer through XML and various scripting languages. However, at the time of this writing, NanoContainer does not appear to be production-ready.
One of the limitations of PicoContainer is that it allows only one instance of
any particular type to be present in its registry. This is could lead to problems if
you need more than one instance of the same class, just configured differently.
For example, you may want to have two instances of a javax.sql.DataSource in
your application, each configured for a different database. This would not be possible
in PicoContainer.
Also, you should know that PicoContainer is only a container. It does not offer any of the other powerful features that Spring has, such as AOP and third-party framework integration.
HiveMind is a relatively new IoC container. Like PicoContainer, it focuses on wiring and configuring services with support for both constructor and setter injection. HiveMind allows you to define your configuration in an XML file or in HiveMind’s Simple Data Language.
HiveMind also provides an AOP-like feature with its Interceptors. This allows you to wrap a service with Interceptors to provide additional functionality. However, this is not nearly as powerful as Spring’s AOP framework.
Finally, like PicoContainer, HiveMind is only a container. It provides a framework for managing components but offers no integration with other technologies.
Avalon was one of the first IoC containers developed. As with many early entrants into a market, some mistakes were made in its design. Mainly, Avalon provides interface-dependent IoC. In other words, in order for your objects to be managed by the Avalon container, they must implement Avalon-specific interfaces. This makes Avalon an invasive framework; you must change your code in order for it to be usable by the container. This is not desirable because it couples your code to a particular framework for even the simplest of cases.
We believe that if Avalon does not adopt a more flexible means of managing components, it will eventually fade out of the lightweight container market; there are other ways of achieving the same results with much less rigidity.
Spring comes with its own very capable web framework. It provides features found in most other web frameworks, such as automatic form data binding and validation, multipart request handling, and support for multiple view technologies. We’ll talk more about Spring’s web framework in chapter 8. But for now, let’s take a look at how Spring measures up to some popular web frameworks
Struts can probably be considered the de facto standard for web MVC frameworks. In has been around for several years, was the first “Model 2” framework to gain wide adoption and has been used in thousands of Java projects. As a result, there is an abundance of resources available on Struts.
The Struts class you will use the most is the Action class. It is important to note
that this is a class and not an interface. This means all your classes that handle
input will need to subclass Action. This in contrast to Spring, which provides a
Controller interface that you can implement.
Another important difference is how each handles form input. Typically, when
a user is submitting a web form, the incoming data maps to an object in your
application. In order to handle form submissions, Struts requires you have
ActionForm classes to handle the incoming parameters. This means you need to
create a class solely for mapping form submissions to your domain objects.
Spring allows you to map form submissions directly to an object without the need
for an intermediary, leading to eaiser maintenance.
Also, Struts comes with built-in support for declarative form validation. This means you can define rules for validating incoming form data in XML. This keeps validation logic out of your code, where it can be cumbersome and messy. Spring does not come with declarative validation. This does not mean you cannot use this within Spring; you will just have to integrate this functionality yourself using a validation framework, such as the Jakarta Commons Validator.
If you already have an investment in Struts or you just prefer it as your web framework, Spring has a package devoted to integrating Struts with Spring. Furthermore, Struts is a mature framework with a significant following in the Java development community. Much has been written about Struts, including Ted Husted’s Struts in Action (Manning, 2002).
| home / programming / spring / 2 | [previous][next] |
| ||||||||||||||||||||
Created: March 27, 2003
Revised: March 23, 2005
URL: http://webreference.com/programing/spring/3
