When traditionally writing business logic processing code, we usually do several things habitually: logging, transaction control, and permission control, etc., and then write the core business logic processing code. When the code is written and look back, I can't help but find that there are hundreds of lines of code that are really used for core business logic processing, as shown in Figure 6-4. Method after method, class after class, just like this, how many spring and autumn have been spent with helpless regrets. Even so, if at the end of the project, it is suddenly decided that a major change in permission control needs to be made, thousands of methods have to be "visited" one by one, and the pain "worst worse".
If you can extract all the common codes in the many methods in Figure 6-4, put them in a place for centralized management, and then dynamically weave these common codes by the container at the specific runtime, at least two solutions can be solved. question:
When Java EE programmers write specific business logic processing methods, they only need to care about the core business logic processing, which not only improves work efficiency, but also makes code changes concise and elegant.
In the future maintenance, since the business logic code and the common code are stored separately, and the common code is stored in a centralized manner, the maintenance work becomes simple and easy.
Aspect-oriented programming AOP technology was born to solve this problem. Aspect is a cross-section, as shown in Figure 6-5, which represents a ubiquitous common function, such as log aspect, permission aspect, and transaction aspect.
Let's take the AOP implementation process of the user management business logic component UserService (see Figure 6-6) as an example to deeply analyze the implementation principle of AOP technology. AOP technology is based on the reflection mechanism and dynamic proxy mechanism of Java language. During the running process of the business logic component, the AOP container will dynamically create a proxy object for the user to call . The functions of the business logic are executed at the same time. In principle, what the caller directly calls is actually the proxy object dynamically generated by the AOP container, and then the proxy object calls the target object to complete the original business logic processing, while the proxy object has synthesized aspects and business logic methods.
Some of the concepts involved in Figures 6-6 are now explained as follows.
Aspect: In fact, it is the realization of common functions. Such as log aspect, permission aspect, transaction aspect, etc. In practical applications, it is usually a common Java class that stores the implementation of common functions. The reason why it can be recognized as an aspect by the AOP container is specified in the configuration.
Advice: It is the concrete realization of the aspect. Taking the target method as the reference point, it can be divided into five types: Before, AfterReturning, AfterThrowing, After and Around. In practical applications, it is usually a method in the aspect class, and the specific type of notification is also specified in the configuration.
Joinpoint: It is the place where the program can insert the aspect during the running process. For example, method invocation, exception throwing or field modification, etc., but spring only supports method-level join points.
Pointcut: Used to define which connection points the advice should cut into. Different advice usually needs to be cut into different join points, and this exact match is defined by the regular expression of the pointcut.
Target object (Target): It is the object that is about to cut into the aspect, that is, the object that is notified. Only the core business logic code is left in these objects, and all the common function codes are waiting for the entry of the AOP container.
Proxy object (Proxy): An object that is dynamically created after the notification is applied to the target object. It can be simply understood that the function of the proxy object is equal to the core business logic function of the target object plus the common function. The proxy object is transparent to the user and is the product of the program running process.
Weaving: The process of applying an aspect to a target object to create a new proxy object. This process can occur at compile time, class loading time and runtime, of course, different occurrence points have different preconditions. For example, if it occurs at compile time, a special compiler that supports this AOP implementation is required; if it occurs at class loading time, a special class loader that supports AOP implementation is required; only at runtime, it can be directly passed through The reflection mechanism and dynamic proxy mechanism of the Java language are implemented dynamically.
Source: http://blog.csdn.net/diqi77/article/details/51673407