IOC and AOP in spring

I. IOC (DI)

Inversion of control inversion, also called (Dependency injection) Dependency injection.

When we use objects, we usually use the keyword class new object directly, so what's the downside? In fact, using new so that the current module has unwittingly and new objects are coupled, and we are usually a higher level of the abstract module calls the underlying implementation module, which also produced a module dependent on the implementation of the concrete, This is in conflict with the interface-oriented abstract programming we advocate in Java, and it also leads to the problem of the module architecture of the system.

Very simple example, when we are doing database operations, always call the DAO layer of the business layer, of course, our DAO will generally adopt the interface development, which satisfies the loose coupling to a certain extent, so that the business logic layer does not depend on the specific database DAO layer. But when we use it, we will be new to the DAO layer of a particular database, which is virtually bound to a particular database, although we can use the abstract factory pattern to get the DAO implementation class, but unless we write the DAO for all the databases at once, the database We still have to change the DAO factory class when we move, so we'll think about new ways

Using the IOC, the implementation of the DAO interface is no longer called the business logic layer to fetch the factory class, but rather through the container (spring) to set the DAO implementation class for our business layer, so the whole process is in turn, formerly our business layer actively to obtain DAO, And now DAO is being set up in the business logic layer, which is the origin of inversion control. With IOC, we can seamlessly implement a database migration without modifying any code.

Second, AOP

Aspect oriented programming is programming for facets.

Assuming we want to add some business logic at the beginning and end of the method, the most straightforward way to think about it is to add some code to the front and back of the method, such as a log, if you can't change the original method, then you think of inheriting the class, overriding the method. Maybe you'll think again, the combination of ways. Suppose now to add this log function to 20 different methods of the front, you can consider the log function out of the package into a class method, but that still want to combine the new 20 classes, combined 20 times.

This must not be reliable. We want a new idea, can write a configuration file, in each need to add log logic inside, all the methods of the class to match the method of the log class, so that you do not have to create 20 classes, combined 20 times the old class, but the problem again, the program will not return the class you regroup (that is, the new combination of dynamic classes) We need to think of new ways.

With AOP, he helps us generate dynamic proxy classes that weave into new business logic, such as transactions, logs, and so on.