Spring - Tutorials vs. Real Life

Question

I am currently finding the process of adding Spring and Hibernate to an existing application, but after reading a lot of tutorials there are a couple more (or many things) that seem strange to me or I'm missing something ...

All the training materials that I found are direct (like most tutorials), as shown in Example A , one controller for query processing (JSP or WS) and an autowire manager class for interacting with the database.

In my case, this does not apply, because the application has a class for processing requests, and then creates an instance of the handler class, which, in turn, creates a new class to handle something else, creating a new class for processing (....) * , and then processes the database connection, as shown in Example B.

My question is how can I make my business logic class n "Springable", i.e. able to make an internal database manager inside it?

Of all the examples I saw, I came up with these alternatives:

• Create autwire for ALL DbManager inside the Controller, and then IoC for all business classes until it reaches the Business Logic n class. This will follow Spring standards, but will involve most code refactoring
• Convert ALL business logic classes to beans
• Add SpringBeanAutowiringSupport.processInjectionBasedOnCurrentContext (this); to business logic class n and use @Autowire to access DbManager

Am I missing something or is there another alternative?

Answer 1

This is just my opinion, but you may be interested.

The basic philosophy of Spring is that creating and configuring objects that participate in a container, but not in business objects, is called IoC or dependency injection. Based on the configuration, the container creates and connects (inserts) objects with each other. This allows you to remove the code of the business classes associated with the creation and configuration (this code can be quite complicated). Thus, your classes will become simpler and cleaner, and can focus on business logic and nothing else.

I believe that business objects should not create each other. Let Spring do it. He does it perfectly.

Just mark your business logic classes depending on its role with one of the stereotypes: @Component , @Service , @Controller (you can find the meaning of stereotypes here ) and enter @Autowired . And if you need a database manager in these classes, enter it the same way.

So, my choice corresponds to point number two: "2. Transform all classes of business logic into beans ..."

Answer 2

You can (and should!) Use Spring Stereotypes for this.

Refer to my previous answer to a similar question for detailed information on the proposed application structure.