Should spring management be “everything” in Java – spring applications?

We are developing a new application and we want to use spring (University project!)

When writing a new spring application, should spring be injected into each object?

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

class AHelper {
    public void doSomething(){}
}

>In this case, should the setter be used to inject ahelper into a? If class a relies on five assistants, should it be injected all? This is a best practice, and if so, what do we get from it? > In addition, if the class ahelper depends on ahelperhelper and ahelperhelper, should the entire dependency chain be configured in XML It doesn't feel right for me!

Solution

In my opinion, it is good to decide which objects are beans and which are not beans at the beginning of the project It can be distinguished by their responsibilities, or in my case, the same layer This rule is easy to explain to other project partners. It minimizes modifications and accidents in the middle of the project

So what I usually do:

>The controller, service and repository layers are spring beans All these are usually interconnected, and I found an overly complex one with some beans and some regular objects. > The model entity is not a spring bean If the model entity is only POJO, the development is usually easier In addition, if you load hundreds of beans in one operation and they are all beans, it may lead to poor performance. > Dto, vo... Well, I don't usually need them, but if I do, I treat them as model entities. > Practical courses There are three types:

>Static method classes: obviously, they cannot be beans It doesn't help you. > Simple objects, such as your own maps: just keep them as regular objects. > Assistants, such as 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 this case: coding, basic path, separator...), so if you make beans, you can get some benefits

>Exceptions, enumerations,...: of course, there are no beans