This week's book giveaway is in the Java 8 forum.
We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line!
See this thread for details.
The moose likes Other Application Frameworks and the fly likes For the authors--What is Spring?? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "For the authors--What is Spring??" Watch "For the authors--What is Spring??" New topic
Author

For the authors--What is Spring??

Mike Firkser
Ranch Hand

Joined: Oct 21, 2003
Posts: 247

I haven't seen too much about Spring. Can you give a high level about what it does? Is it an alternative to EJBs? If not, what is it an alternative too.

Thanks in advance.


Mike Firkser
Rutgers '84
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Originally posted by Mike Rutgers:
I haven't seen too much about Spring. Can you give a high level about what it does? Is it an alternative to EJBs? If not, what is it an alternative too.


Ah...the ever-popular "What is Spring?" question. You know, I've not yet been able to refine my "elevator speech" on Spring, so I don't have a short answer. What follows is my best shot at describing Spring:

In its simplest form, Spring is a lightweight inversion of control (IoC, aka dependency injection) container framework. But what does that mean?

Applications are made up of objects, which are to some degree coupled with each other. If the coupling is too high, the application is unwieldy, difficult to test, difficult to manage, and exhibits behavior of "whack-a-mole" type bugs (fix one bug, create another). But coupling is necessary to a degree (no coupling, no system). The key is to keep the coupling to a minimum.

Coding to interfaces helps, but at some point you have to instantiate your objects. If a FooImpl object depends on a Bar object, how does FooImpl get its Bar? One way is for FooImpl to have a line like "Bar bar = new BarImpl()", but this creates a direct coupling between FooImpl and BarImpl. IoC twists it so that instead of creating or retrieving a Bar, Foo Implis *given* a Bar (typically through a constructor argument or a setter method).

The nice thing about this is that FooImpl doesn't know (or care) what particular implementation of Bar it gets. It could be getting a POJO implementation, an EJB implementation, a web-service implementation, or a mock implementation (for unit-testing). The point is that FooImpl is only coupled to the Bar implementation through its interface.

So, as an IoC container, Spring provides a mechanism where the actual instantiation and wiring of dependent objects together is defined external to the application code (typically in XML) and performed by the container.

But Spring is more than that (I told you that this wouldn't be an elevator-speech). Spring is also an aspect-oriented framework. By providing AOP features, Spring enables you to take decoupling a step further by letting you decouple your objects from higher-level concerns (such as security and transactions). Instead of coding transactional boundaries in a method definition, you declare an aspect that wraps a method in a transaction.

Once you have declarative transactions, you've just enabled POJOs (or plain JavaBeans) with one of the most significant powers of EJBs. Declarative security is also possible with Spring. And remoting. So, in many ways, Spring provides a viable alternative to EJBs.

Adding to all of that, Spring MVC is a Model 2 framework built on top of Spring. So, Spring can also be an alternative to Struts or WebWork.

Then again, it's quite possible to integrate Spring with other MVC frameworks such as Struts, WebWork, JSF, or Tapestry. In fact, one of my preferred application stacks includes Tapestry in the presentation layer, Spring in the service layer, and Hibernate in the persistence layer.

And then there's more...but this post is getting long enough, so I'll leave it up to you to research what else Spring can do (or ask and I'll tell you).


Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
Mike Firkser
Ranch Hand

Joined: Oct 21, 2003
Posts: 247

Thanks - it seems to not to lend itself to a quick explanation.
Regis Santos
Ranch Hand

Joined: Mar 23, 2004
Posts: 31
Coding to interfaces helps, but at some point you have to instantiate your objects. If a FooImpl object depends on a Bar object, how does FooImpl get its Bar? One way is for FooImpl to have a line like "Bar bar = new BarImpl()", but this creates a direct coupling between FooImpl and BarImpl. IoC twists it so that instead of creating or retrieving a Bar, Foo Implis *given* a Bar (typically through a constructor argument or a setter method).


I confess that I didn't get it. I know that I have to use the "new" operator to get a new instance of an object.

I think that Spring does it through the BeanFactory interface. But I supposed that the BeanFactory doesn't create an object instance using the "new" operator.

How does the BeanFactory create the object? Does it create using the Class.forName() method using the value of the "class" attribute of "bean" tag?

Thanks!


Regis Santos
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Originally posted by Regis Santos:
How does the BeanFactory create the object? Does it create using the Class.forName() method using the value of the "class" attribute of "bean" tag?


Although I don't have the Spring source code handy, I imagine that this is how it works. But, that's not the point.

The point is that my FooImpl isn't responsible for obtaining an instance of Bar. So, instead of:



Or maybe it looks like this:



Using IoC, FooImpl might look like this:



Notice the difference? In the first incarnation of FooImpl, FooImpl was coupled with BarImpl directly. In the second version, FooImpl is no longer coupled to BarImpl...but BarFactory is. And FooImpl is still responsible for getting its own Bar.

But, in the third incarnation, FooImpl only knows about Bar. It isn't coupled to BarImpl. FooImpl is given an instance of Bar either through its constructor or through its setter. Who give the Bar instance to FooImpl? The IoC container (which is likely Spring, but could also be PicoContainer or any one of the other IoC containers out there).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: For the authors--What is Spring??
 
Similar Threads
Spring in Action: 3rd edition - Questions on Spring
Why EJBs?
What are the best web server for learning?
Spring Web Module vs Spring MVC Framework
Spring Persistence with Hibernate book required or assumes any hibernate or ORM knowledge?