Pojos in spring context: valid pattern or anti-pattern?

[javadev4942]

Hi,

I came across a design architecture I hadn't seen before -- no surprise there, but maybe you could enlighten me.

1) Many JPA entity pojos are defined in the Spring context using XML. The pojos have no injected dependencies. They are not subclassed. They are not used within another bean definition. They look like this:

<bean id="my.entities.MyEntityPojo" class="my.entities.MyEntityPojo" singleton="false"/>

@Entity
@Table(name="my_table")
public class MyEntityPojo implements Serializable{
...
}

2) The pojos are accessed via the appContext.getBean method, wherever they are needed throughout the entire application. Like so:

MyEntityPojo pojo = (MyEntityPojo) appContext.getBean("my.entities.MyEntityPojo");

3) The idea is that creating an object with 'new' is bad. appContext.getBean is better, the pojos benefit from the Spring context. It is more efficient, the JVM is not burdened with garbage collection, and the objects are pooled and managed with Spring goodness.

4) I will repeat, there are no injected dependencies and the bean id is not used within another bean. There are no plans for doing so.



Ok. Does anyone have any thoughts on point #3? Is this genius, or madness? Have I gone down the rabbit hole or are there good reasons for doing this?

Thanks!

[julien.dubois]

I disagree with #3 : as you have singleton="false" in your configuration, Spring does have to create a new object each time.
So you do have the creation of new objects (it's Spring that creates them for you, and not you directly, that's the only difference), and there is some GC at the end to clean them up. It's even a lot less efficient than doing the "new" yourself, as Spring does quite a lot of work behind the scenes to create the object (this has been greatly improved in the latest Spring 2.0 releases, some of my object creations are 20x faster now... I guess the concurrence of Guice is good...).

Besides :
- You are not using DI or AOP, you do not have any specific object lifecycle to handle
- You use your domain objects directly, so you do not really need a factory. If those were business services, an interface would be useful, but for those objects I don't think you will want to use interfaces.

So I think this is overkill, time-consuming (instead of doing a "new", this is a lot more work), and bad for performance.

[karldmoore]

Surely the point is that you are not actually in control of the creation, when JPA retrieves items from the database, it is the one that creates the new entity. As for pooling the objects and garbage collection, if the object is simple it should be inexpensive to create.

[wpoitras]

Hi,
I came across a design architecture I hadn't seen before -- no surprise there, but maybe you could enlighten me.

3) The idea is that creating an object with 'new' is bad. appContext.getBean is better, the pojos benefit from the Spring context. It is more efficient, the JVM is not burdened with garbage collection, and the objects are pooled and managed with Spring goodness.

Ok. Does anyone have any thoughts on point #3? Is this genius, or madness? Have I gone down the rabbit hole or are there good reasons for doing this?

I'm on the madness/rabbit hole side. "new" is not inherently bad. There isn't much point to a "dependency injection" container when you aren't doing any. And besides, its not more efficient than new, the JVM still has to garbage collect them as prototype objects are not managed at all by the container beyond creation. And your code has to have a handle on an ApplicationContext/BeanFactory instance and possibly ties your business code to Spring. If you really wanted to use an object to create an entity you'd be better off wrapping it in something application specific and using a Spring context under the covers. But I'd recommend using "new" if you aren't doing any special to the entity in the context.

[javadev4942]

I disagree with #3 : as you have singleton="false" in your configuration, Spring does have to create a new object each time.
So you do have the creation of new objects (it's Spring that creates them for you, and not you directly, that's the only difference), and there is some GC at the end to clean them up. It's even a lot less efficient than doing the "new" yourself

That was my understanding of Spring, the JVM, and I suppose of the universe.

AOP is an interesting point, but I would expect that in a Dao or service manager . I tried to summarize the 'technical discussion' I had as point #3, because I was genuinely curious why someone would do this. The closest to a technical response I had was that the JVM was bad at creating and disposing of even simple objects but that the Spring container was very good at doing so. Thanks for the response!

[wpoitras]

Not only is the JVM not "bad" at it, the most modern ones are really good at it. Especially for very short lived objects. Known as young generation objects, if they a short enough life they are in a different pool as the longer lived objects, known as the "tenured generation".

[karldmoore]

There are actually quite a few articles out there that talk about performance myths.
http://www.ibm.com/developerworks/li...-jtp01274.html