Since there are so many things in the Spring family, it’s not practical to write them all at once. So this time, let’s update Spring’s “core” knowledge: AOP and IOC
It is important to understand AOP and IOC both in the beginning and in the interview. Time at school, I was not asked Mybatis/Hibernate/struts 2 such a framework, and Spring is often asked.
As a reading benefit, I have organized Spring related learning materials (including handwritten PDF, brain map, interview questions), including Spring Boot, Spring Cloud, Spring IOC, Spring AOP, etc., and now I share them with Java programmers who read this article for free. If you need to click the link below to get ~
The most complete Spring study notes + interview questions
Why use Spring
When I first learned Spring, I thought, “What the hell are these IoC and AOP?” There are a lot of terms like “Inversion of Control,” “Dependency Injection,” and “Facet-Oriented Programming.” You’re pulling my leg.
I learned a lot of things about IOC in the beginning, and I ended up dealing with “creating objects”? Are you kidding me?? Wouldn’t it be nice if I just created a new object?
The idea that this is obviously less code, more thinking.
When we write code, we don’t just need to be able to implement the functionality, we also need to “maintain” the code we’ve written. If our code is poorly written, the cost of “maintenance” is high.
What does maintenance actually do?
- Something is wrong and we need to find out which piece of code is the problem
- Adding new features on top of existing ones (known as iteration)
Faced with repetitive/tedious non-business code:
- If something goes wrong with the program, we’ll see, okay? There is no guarantee that duplicate code will not be a problem.
- If we want to add a new function, we still have to write it the same way, right? More and more code, more and more… .
The last “MyBatis” tutorial also said that our JDBC is well written, the efficiency of the operation is also a bar. But JDBC had so many details that we had to “do it ourselves,” adding all kinds of “repetitive” code.
We use the ORM framework, so we can be more “focused” to implement our own business, ORM framework to block the “duplicate” code, code maintenance is easier than JDBC.
Spring IOC addresses the issue of object management and object dependency.
Spring AOP addresses the problem of non-business code extraction.
(If there is no basic students here, may not understand, the following to explain the explanation should be no problem)
Spring IOC
When it comes to Spring IOC, a casual Internet search will reveal the terms “Dependency Injection” and “Inversion of Control.”
A lot of people try to explain these two words, but they’re hard to explain, they’re really hard to explain.
Spring IOC addresses the issue of object management and object dependency. All of our objects are created by new, but if we use Spring, we will give the objects to the “IOC container” to manage.
Three crooked this force make a matter. “Dependency Injection” and “Inversion of Control” were not mentioned, and now there is “IOC Container”.
What is an “IOC Container”? We can think of it as a “factory” that manages all objects, including object creation and dependencies among objects, etc. When we need the object, we pull it out of the “factory”.
Inversion of control refers to the fact that an object that was new “by ourselves” is now given to the IOC container. Giving “control” of this object to “the other party”. Inversion of Control is more of an idea, or design pattern, of handing over to someone else something you can control.
“Dependency injection” refers more to the way the idea of “inversion of control” is implemented: instead of objects creating or managing their own dependencies, dependencies are “automatically injected” into objects that need them.
The simplest way to think about Dependency Injection and Inversion of Control is that our objects are created “by ourselves”, but now we give the creation permissions and dependencies to an “IOC container” to manage.
Whisper: I personally do not like to think about the meaning of each word, a lot of time the big guys are also difficult to explain clearly. If you are a beginner, you don’t need to worry too much about the specific meaning of each noun. There is no need to dig deeper.
Now again, why do we give objects to an “IOC container” to manage? To understand this, I suggest looking at the “factory pattern” I wrote about.
In theory, we can also think of the “IOC container” as a “factory”. The advantages of using the IOC are:
- The object centralized unified management, easy to modify
- Decrease coupling (callers don’t have to assemble their own, and they don’t have to care about the implementation of the object, they can just fetch it from the “IOC container”)
What does the IOC need to learn?
When we use Spring, the first thing we need to learn is how to put objects in the “IoC container”.
Spring provides four ways:
- annotations
- XML
- JavaConfig
- Groovy DSL-based configuration
In summary: We assemble beans more often with XML configuration plus annotations, and annotations are the majority of the way.
After placing objects in the “IOC container”, objects are related to each other. We need to tell Spring the dependencies between objects and ask it to help us resolve the dependencies between objects.
Don’t get too complicated about the relationship between objects. In everyday development, A lot of times it’s just that object A has properties of object B in it.
Typically we inject an object dependency through a constructor or property (setting method)
For example, in daily development, many times we use the @Component annotation to identify an object in an “IOC container” and the @Autowired annotation to inject the object
The following diagram summarizes the various ways in which beans can be defined and injected.
Spring AOP
Aspect Object Programming (AOP) : Aspect Object Programming (AOP)
Spring AOP basically does this: “Take duplicate code and dynamically populate” facet class code “on a business method at run time.”
For example, we now have the following code:
The above code is actually the core of one line of code: “save user object to database”
session.save(user);There is definitely more than user in our database table, and there is definitely more than add() method in our database. So you can imagine writing “open transaction” and “close transaction” code for every operation on the database.
This kind of code is repetitive to us, so we want to “extract” it.
If we simply use OOP (object-oriented) thinking to optimize the code, we may end up with something like this:
Even though this might seem like a small amount of code, if you think about it: the update()/delete() method also has duplicate code like aop.begin().
We want to “eliminate” duplicate code. What can we do? At this point we should think of “dynamic proxies”, where we can “enhance” objects and write non-business code on the logic to be “enhanced”.
Once that’s done, we can call methods through the “enhanced object,” and finally get rid of “duplicate code.”
The effect might be as follows:
The above is the agent we wrote manually to extract “non-business code”. There are many scenarios like this: for example, we need to do permission control, we need to verify parameters and so on.
Spring supports AOP, which allows you to extract “non-business code” without having to “manually” write proxy objects yourself.
We can experience a wave of Spring AOP in action with the following comparison:
The effect is as follows:
conclusion
Suggestion: Take a look at “factory mode” before learning about IOC. Before learning about AOP, take a look at “Proxy Patterns”
Understanding the “factory pattern” will help us understand why we don’t directly new objects. Understanding the “proxy pattern” will help us understand that the underlying technology of Spring AOP is actually “dynamic proxy”, which will make learning about IoC and AOP a lot easier.
One more thing is not to be frightened by “nouns”. When I didn’t understand a certain technology before, I listened to some nouns, which I didn’t understand at all. Then you may think that this technology will be very awesome, in fact, and so really contact down, after learning, in fact, found that it is just so.