Preface
As a coder engaged in Java development, the importance of Spring is self-evident. You may be dealing with Spring frameworks every day. Spring is just as named, bringing a spring-like comfort to the development of java applications. Spring can be said to be a necessary foundation for any Java developer to reach the advanced technology. Of course, it is not easy to learn Spring well, especially to understand the underlying principles of Spring. It takes a lot of time and energy to study it carefully, and constantly trial and error and summarize in actual projects in order to form your own thinking and understanding. The blogger had a very shallow understanding of Spring at the beginning, and it was possible to rely on the problem that Du Niang could solve in a general way when encountering problems in the project. However, for more than a year since Spring has been in contact with Spring, the understanding of its framework system is quite chaotic, and the deep technology is still like a fog, and it has not formed its own cognition and understanding, which is very unfavorable to the improvement of programming technology. In view of this, I decided to calm down and learn the Spring framework systematically from beginning to end, and record the learning details and share technical knowledge through the form of a blog. Okay, let's get to the point-
Introduction to the core Spring framework
DI (Dependency Injection), dependency injection, and another concept we often hear about, actually implements the same functions as IOC (control inversion), but the same functions are explained from different perspectives. The blogger here won’t go to analyze too much, there are a lot of explanations on Baidu. What we need to know is what dependency injection is and why dependency injection is. To understand these two points, I think that learning Spring is the best in terms of thinking.
When Spring is not used - that is, when there is no dependency injection, it is difficult to achieve mutual functional collaboration between classes of Java applications. If a certain class (A) needs to implement its functions, if it needs to rely on the collaboration of another class (B), it is necessary to actively create a class B object in Class A to complete the functions using Class B methods (you should not worry about static methods and other situations here). This is equivalent to Class A being responsible for the management of the entire life cycle of Class B objects. In extremely simple cases, it seems that there is no problem to new objects of another class in one class, but the collaborative relationship between complex application classes and classes is often multilateral. We do not know how many alternative objects the implementation of a class function will rely on to cooperate. Therefore, creating objects in a class and managing the entire life cycle of the object will cause high code coupling and unimaginable complexity. So, imagine that if we can hand over the life cycle of an object to a third-party component for management, and when a class needs another object, the third-party component will be created directly to it. In this way, the class can only focus on the implementation of its own functions without managing the life cycle of other class objects, the functions of such a class are much simpler. Yes, you must have understood that Spring is this third-party component. We just need to tell Spring (container) which objects need to be managed, and we don’t have to care about how the Spring framework creates objects. In this way, when a certain class A requires class B object, if class B has been declared and handed over to the Spring container management, then when the program runs to class A and requires class B, the Spring container injects class B objects into class A through dependency injection to assist in completing business functions. Through dependency injection of third-party components, objects no longer need to create and manage dependencies between classes themselves. There are also many ways to create dependency injection of objects, such as interface injection, construction method injection, setter method injection, etc. Speaking of this, you should have a relatively straightforward understanding of dependency injection. As for why dependency injection is needed, the above article has already explained it very clearly. In order to reduce the coupling between components in the code, we should first use simple examples to intuitively experience the benefits of dependency injection over managing objects yourself -
public class Man implements Human { private QQCar car; public Man() { this.car = new QQCar(); } @Override public void xiabibi() { } public void driveCar(){ car.drive(); }}There are two implementations of interface Car: Mercedes-Benz and QQ car. In the above codes of Man and QQCar, the veteran driver only created QQ car objects through the constructor, so he can only drive QQ car. So what should the veteran driver do if he wants to drive Mercedes-Benz? Do you ask him to recreate the Mercedes-Benz object? Such highly coupled code seems to be helpless, so we will make some improvements to the above code by injecting objects:
public class Man implements Human { private Car car; public Man(Car car) { this.car = car; } @Override public void xiabibi() { } public void driveCar() { car.drive(); }}The above code blocks out specific objects based on polymorphic characteristics through constructor interface injection, so that veteran drivers can drive whatever they want. This is the benefit of dependency injection.
AOP (Aspect Oriented Programming), face-oriented programming. In daily development, when we complete a certain business function, we write a lot of code. When we finally optimize the code, we find that the code that actually completes the business may be just two sentences, and the rest are not very relevant to this part of the business. It is completely extracted just to implement a certain technology code. So naturally, we will extract it into a tool class, so that everything you use is ok with just calling the tool method. Let’s look at it a little higher. In addition to completing related business functions, the functional components of each business module involve additional operations such as logs, transactions, and security control. These are not the core functions of the module, but they are indispensable. If these extra functions are added to the code, each component of the business system will appear too repetitive and make the business code appear confusing and not pure enough. At this time, you ask God, can your business code only focus on business implementation and ignore any irrelevant things such as logs, transactions, etc.? Oh, God said it was OK, so there was AOP. If the purpose of dependency injection is to keep cooperative components in a relatively loose coupling state, AOP separates the functions spread across the application to form reusable components. In layman's terms, logs, transactions, etc. are all reusable components. We can completely extract the logs, transactions, security and other functional codes scattered in various parts of the business code and become a separate tool component. Declare it as a functional section in Spring's configuration, and then tell Spring where and when you want to use (cut into) these reusable components. This is my simple interpretation of the face-oriented section. This article is just an introduction, so the blogger will just briefly explain the concept and will not make specific code or configuration implementations. It will be presented in subsequent blog posts. Welcome to take a look.