Should 'everything' be spring managed in a Spring application?

Question

We are working on a new application and we want to use Spring (college project!)

When you are writing a new Spring application, should each and every object be Spring injected?

class A {
    ...
    AHelper helper = new AHelper();
    helper.doSomething();
    ...
}

class AHelper {
    public void doSomething(){}
}

1. In this case, should AHelper be Spring injected into A using a setter? If class A depends on 5 helpers, should all of them be injected? Is that the best practice and if yes what are we getting out of it?

2. Also, if class AHelper depends on AHelperHelper and that in turn depends on AHelperHelperHelper, should this entire dependency chain be configured in the XML. It just feels wrong to me!

Answer 1

In my opinion it is preferable to decide at the beginning of a project which kind of objects would be beans and which wouldn't. It can be based on their responsability or, as in my case, the layer where they are placed. This rule is very easy to explain to other team members and it minimizes modifications in the middle of the project and surprises.

So, what I usually do:

• Controller, service and repository layers are Spring beans. All of them are usually wired together, and it's an overcomplication to have some beans and some regular objects (POJOs) at the same time.

• Model entities are not Spring beans. Developement is usually simpler if model entities are just POJOs. Also, if you load hundreds of them in a single operation, and they are all beans, it can lead to poor performance.

• DTO, VO... well, I usually don't need them, but if I do, I treat them as model entities.

• Utility classes. There are three kinds of them:

  • Static method classes: obviously they must not be beans. It won't help you.

  • Simple objects, for example your own kind of map: just leave them as regular objects.

  • Helpers, such as an CsvFileConstructor: In my opinion these are just services, but some people prefer to put them in util package. Anyway, they usually need some configuration (in a CSV case: encoding, base path, separator...), so you can get some benefits if you make them beans.

• Exceptions, enums, ...: of course, no beans.

Answer 2

I've seen projects in which every object is injected, and it's a nightmare.

I would identify the larger-scale components that you're likely to build and create them as Spring beans if:

1. you're likely to want to configure them
2. use Spring AoP on them (e.g. for transactions etc.)
3. clients are likely to want to recompose your application using these components

For instance, in my current project, we Spring-enable new larger scale components that we may want to enable/disable for release, or that other teams will consume, or that we need to enable JMX (via Spring AoP) for.