Introduction to di and AOP in spring Basics

preface

As a coder engaged in java development, the importance of spring is self-evident. You may be dealing with the spring framework every day. Spring is just like its name, which brings a spring like feeling to the development of Java applications. Spring can be said to be the necessary foundation for any Java developer to go to the high level of 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, and constantly try and summarize in the actual project, so as to form your own thinking and understanding. Bloggers have a shallow understanding of spring at first. Problems encountered in the project can probably be solved by Du Niang. However, in contact with spring for more than a year, the cognition of its framework system is quite messy, and the deep technology is still in a fog. 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 to systematically learn the spring framework from beginning to end, record learning bits and pieces in the form of blog, and share technical knowledge. It's like throwing a brick to attract jade. Well, let's get down to business

Spring framework core introduction

Di (dependency injection), dependency injection, and another concept we often hear about IOC (control inversion) actually implement the same functions in the final analysis, but the same functions are described from different angles. Bloggers here don't have much discrimination. Du Niang has a lot of explanations. What we need to know is what dependency injection is and why dependency injection is needed. To understand these two points, I think the study of spring is on the road in thought.

When spring is not used -- that is, when there is no dependency injection, it is difficult for Java application classes to realize mutual functional cooperation. If a class (a) needs to rely on the cooperation of another class (b), it needs to actively create class B objects in class A, Only then can class B methods be used to complete the functions (here, the observer should not worry about static methods and so on). This means that class a needs to be responsible for the management of the whole life cycle of class B objects. In extremely simple cases, there seems to be no problem in creating new objects of another class in one class, but the cooperative relationship between complex application classes and classes is often multilateral. We do not know how many alternative objects will be relied on for the implementation of a class function, so we create objects in the class and manage the whole life cycle of the object, It will cause high coupling of code and unimaginable complexity. Then, imagine that if we can hand over the life cycle of an object to a third-party component for management, when a class needs another object, the third-party component will be directly created and handed over 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. In this way, the functions of the class are much simpler. Yes, you must have understood that spring (container) is this third-party component. We just need to tell spring (container) which objects need to be managed, and we don't need to care about how the spring framework creates objects. In this way, when a class a needs class B objects, if class B has been declared and handed over to the spring container for management, then when the program runs to class A and needs class B, the spring container injects class B objects into class a through dependency injection to assist in completing business functions. Through the dependency injection of third-party components, objects no longer need to create and manage the dependencies between classes. There are also many ways to create object dependency injection, such as interface injection, construction method injection, setter method injection and so on. At this point, you should have a more straightforward understanding of dependency injection. As for why we need dependency injection, it has been made clear above. In order to reduce the coupling between components in the code, we'd better intuitively feel the benefits of dependency injection over managing objects by ourselves through a simple example

The interface car has two implementations: Mercedes Benz and QQ. In the above highly coupled codes of man class and qqcar class, the old driver only creates QQ car objects through the constructor, so he can only drive QQ cars. What should the old driver do if he wants to drive Mercedes Benz? Do you want him to re create the object of Mercedes Benz? Such highly coupled code seems to be helpless, so let's improve the above code by injecting objects:

According to the polymorphic characteristics, the above code shields the specific object implementation by means of constructor interface injection, so that the old driver can drive whatever car he wants. This is the benefit of dependency injection.

AOP (aspect oriented programming), aspect oriented programming. In daily development, when we complete a business function, we write a pile of code. At the end of code optimization, we find that the code that really completes the business may be only two sentences, while the rest are not related to this part of the business. The code just to realize a certain technology can be completely separated, so it is very natural, We will extract it into a tool class, so that where we use it, we only need to call the tool method. Let's look a little higher. In addition to completing relevant business functions, the functional components of each business module all involve additional operations such as logs, transactions, security control, etc. These are not the core functions of the module, but they are indispensable. If these additional functions are added to the code, each component of the business system is too repetitive, and the business code is chaotic and not pure enough. At this time, you ask God, can you let your business code only focus on the implementation of the business and ignore irrelevant things such as logs and transactions? Oh, God said no problem, so there was AOP. If the purpose of dependency injection is to keep the collaborative components in a loose coupling state, AOP is to separate the functions throughout the application to form reusable components. Generally speaking, logs, transactions, etc. are reusable components. We can completely separate the log, transaction, security and other functional codes scattered throughout the business code into a separate tool component, declare it as a functional aspect in the spring configuration, and then tell spring where you want to be Just use (cut in) these reusable components at any time. This is my simple definition of aspect oriented. This article is only an introduction, so the blogger just briefly expounds the concept without specific code, configuration and implementation. It will be presented in subsequent blog posts. Welcome to clap bricks.