Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

3 Answers 3

up vote 6 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
    
This is also a valid answer for me! Sadly, I can choose only one answer. –  Rishabh Oct 12 '12 at 10:55

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.

share|improve this answer
    
Hi Donal, Would your answer be same if the ClassA is a domain class which is rich in business logic? –  Sameer Patil Oct 10 '12 at 14:25

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.