When not to use Spring to instantiate a bean?

Question

I am trying to understand what would be the correct usage of Spring. Not syntactically, but in term of its purpose. If one is using Spring, then should Spring code replace all bean instantiation code? When to use or when not to use Spring, to instantiate a bean?

May be the following code sample will help in you understanding my dilemma:

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
 ClassA ca = new ClassA();
 ca.setName(name);
 caList.add(ca);
}

If I configure Spring it becomes something like:

List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
 ClassA ca = (ClassA)SomeContext.getBean(BeanLookupConstants.CLASS_A);
 ca.setName(name);
 caList.add(ca);
}

I personally think using Spring here is an unnecessary overhead, because

1. The code the simpler to read/understand.
2. It isn't really a good place for Dependency Injection as I am not expecting that there will be multiple/varied implementation of ClassA, that I would like freedom to replace using Spring configuration at a later point in time.

Am I thinking correct? If not, where am I going wrong?

Answer 1

You're right, Spring is inappropriate for the use case you listed. Spring is better used for managing external dependencies (like plugging a JDBC connection into a DAO) or configurations (like specifying which database type to use). In your example, if the bean type was liable to change, then you'd use an interface to specify the bean, and instantiate the beans using a Factory. You'd use Spring to specify which factory to use, and inject that into the class that needed to instantiate the beans. You could then have several different factories that created several different types of beans (that all supported the bean interface), and configure that appropriate one at installation (or update) time.

Answer 2

I'd use Spring (or another DI system) between layers, direct instantiation within layers.
So a class that creates a bean that leaves the scope of that class, to some (functionally) external system, possibly defined by that system or some communications layer, would be created through DI. Another bean created purely for internal use within the application layer is created directly, for both code clarity and (in large systems just as important) performance reasons.

• Rishabh: This is also a valid answer for me! Sadly, I can choose only one answer.

Answer 3

If it is a bean, you should let Spring build it (except you can supply a factory bean — I've used that where I needed to return a specific subclass dependent on a system property — and you should consult the documentation on the @Configuration and @Bean annotations if you're doing that). If it isn't a bean, but rather just a Plain Old Java Object, you've no need to use Spring to make it at all. POJOs are useful, but won't get dependency injection, AOP wrappers, etc. as those are the things that Spring adds for you.

The fundamental decision is whether or not it is really a bean, or just some ordinary object that happens to follow some bean conventions (e.g., method naming). I can't guess which is really the case from the small example you gave.

• Sameer Patil: Hi Donal, Would your answer be same if the ClassA is a domain class which is rich in business logic?

Answer 4

I might be wrong experts please correct.

The whole concept of Bean in spring context is Spring Container is taking care of object. It's birth it's scope lifecycle death etc... It's like it's a caretaker of the object. The application which needs it injects it.

So while taking a decision during design of your module always think whether you want Spring framework to take care or it's a simple object whose lifecycle is enclosed in a method.

As previously suggested dao objects jms queues objects etc are heavy and better left to the expert that is Spring framework to take care of it.