AOP knowledge arrangement
AOP (Aspect-Oriented Programming): Aspect-Oriented Programming. OOP (Object-Oriented Programming) object-oriented programming. We are already familiar with OOP. For AOP, we may think it is a new feature. In fact, AOP is a supplement to OOP. OOP is oriented to vertical programming. Inheritance, encapsulation, and polymorphism are its three major characteristics. , while AOP is horizontally oriented programming.
Aspect-Oriented Programming (AOP) complements Object-Oriented Programming (OOP) by providing another way of thinking about program structure. The key unit of modularization in OOP is the class (classes), and the unit of modularization in AOP is the aspect. Aspects can modularize concerns such as transaction management across multiple types and objects.
AOP framework is an important part of Spring. But the Spring IoC container does not depend on AOP, which means that you have the right to choose whether to use AOP or not. AOP is a complement to the Spring IoC container, making it a powerful middleware solution.
The role of AOP in the Spring Framework provides declarative enterprise services, especially as an alternative to EJB declarative services. The most important service is declarative transaction management (which I think is the most used by AOP). Allows users to implement custom aspects and use AOP to improve the use of OOP.
1. AOP concept:
To learn AOP, of course, you must first understand its many conceptual terms: Aspect: The modularization of a concern, which may cross multiple objects. Transaction management is a good example of cross-cutting concerns in J2EE applications. In Spring AOP, aspects can be implemented using schema-based or @Aspect annotation-based methods.
Joinpoint: A specific point during program execution, such as when a method is called or when an exception is handled. In Spring AOP, a join point always represents the execution of a method. Advice: An action performed at a particular join point of an aspect. These include different types of advice such as "around", "before", and "after" (the types of advice are discussed in a later section). Many AOP frameworks (including Spring) use interceptors as their advice model and maintain a joinpoint-centric chain of interceptors.
Pointcut: An assertion that matches a join point. Advice is associated with a pointcut expression and runs on join points that satisfy this pointcut (for example, when a method of a particular name is executed). How a pointcut expression matches a join point is at the heart of AOP: Spring uses the AspectJ pointcut syntax by default.
Introduction: Used to declare additional methods or properties on a type (also known as an inter-type declaration). Spring allows the introduction of new interfaces (and a corresponding implementation) to any proxied object. For example, you can use imports to make a bean implement the IsModified interface in order to simplify the caching mechanism. Target Object: The object informed by one or more aspects. Also known as an advised object. Since Spring AOP is implemented through runtime proxies, this object is always a proxied object.
AOP Proxy (AOP Proxy): An object created by the AOP framework to implement aspect contracts (such as informing method execution, etc.). In Spring, AOP proxies can be JDK dynamic proxies or CGLIB proxies. Weaving: Connect aspects to other application types or objects and create a notified object. These can be done at compile time (e.g. with the AspectJ compiler), class loading time and runtime. Spring, like other pure Java AOP frameworks, does weaving at runtime.
Notification Type:
Before advice: An advice that executes before a join point, but which cannot prevent the flow of execution before the join point (unless it throws an exception). After returning advice: Advice that executes after a join point completes normally: for example, a method returns normally without throwing any exceptions. After throwing advice: Advice that is executed when a method throws an exception and exits. After (finally) advice: Advice that is executed when a join point exits (whether it is a normal return or an abnormal exit). Around Advice: Advice that surrounds a join point, such as a method call. This is the most powerful type of notification. Surround advice can be used to accomplish custom behavior before and after method calls. It also chooses whether to continue executing the join point or simply return its own return value or throw an exception to end execution.
Surround notifications are the most commonly used notification type. Like AspectJ, Spring provides all types of advice, and we recommend that you use the simplest possible advice type to achieve the functionality you need. For example, if you just need the return value of a method to update the cache, it's better to use post advice rather than wrap around advice, although wrap around advice can do the same thing. Using the most appropriate type of advice can simplify the programming model and avoid many potential errors. For example, you don't need to call the proceed() method for wraparound advice on JoinPoint, there will be no call problems.
Here, I will not write more about AOP based on @AspectJ, because I prefer to use ProxyFactoryBean to create AOP proxy in Spring.
2. Use the ProxyFactoryBean to create the AOP proxy:
The basic way to create an AOP proxy in Spring is to use org.springframework.aop.framework.ProxyFactoryBean. This class provides complete control over the application's pointcuts and notifications (including the order in which they are applied). Like other FactoryBean implementations, ProxyFactoryBean introduces a layer of indirection. If you define a ProxyFactoryBean named foo, objects that reference foo will see not the ProxyFactoryBean instance itself, but the object created by the getObject() method in the ProxyFactoryBean implementation. This method will create an AOP proxy that wraps a target object.
The ProxyFactoryBean class itself is also a JavaBean, and its properties are mainly used for the following purposes:
Specify the target object you wish to proxy to specify whether to use CGLIB.
Some main properties are inherited from org.springframework.aop.framework.ProxyConfig (this class is the parent class of all AOP proxy factories in Spring). These main attributes include: proxyTargetClass: When this attribute is true, the target class itself is proxied rather than the interface of the target class. If the value of this property is set to true, a CGLIB proxy will be created. optimize: Used to control whether agents created via CGLIB use aggressive optimization strategies. Users are not recommended to use this setting unless they fully understand how the AOP proxy handles optimizations. Currently this property is only used for CGLIB proxies; it has no effect on JDK dynamic proxies (the default proxy). frozen: If a proxy configuration is frozen, no modifications to that configuration are allowed. This is useful for simple optimizations and when the caller is not expected to manipulate the proxy (via the Advised interface) after the proxy is created. The default value is false, that is, operations like adding additional notifications can be performed. exposeProxy: Determines whether the current proxy is exposed in a ThreadLocal so that it can be accessed by the target object. If the target object needs to obtain a proxy and the exposeProxy property is set to true, the target object can use the AopContext.currentProxy() method.
aopProxyFactory: Use the implementation of AopProxyFactory. This provides a way to customize whether to use dynamic proxies, CGLIB or other proxy strategies. The default implementation will choose a dynamic proxy or CGLIB as appropriate. There should be no need to use this property in general; it was designed to add new proxy types in Spring 1.1.
Other properties that need to be specified in ProxyFactoryBean include: proxyInterfaces: A string array of interface names to be proxied. If not provided, a CGLIB proxy will be used for the target class.
interceptorNames: A string array of Advisors, which can include names of interceptors or other advisors. The order is important, the first will be served first. That is, the first interceptor in the list will be the first to intercept the call. The name here is the name of the bean in the current factory, including the name of the bean in the parent factory. You can't use a bean reference here because that would cause the ProxyFactoryBean to ignore the advice's singleton setup. You can suffix an interceptor's name with an asterisk (*). This will cause all notifiers in this application whose names begin with the part before the asterisk to be applied.
Singleton: Whether the factory should return the same object, no matter how often the method getObject() is called. Several FactoryBean implementations provide this method. The default value is true. If you wish to use stateful notifications - for example, stateful mixins - you can use prototype notifications by setting the value of the singleton property to false.
3. JDK and CGLIB based proxy:
If a class of the target object that needs to be proxied (hereafter we will simply call it the target class) does not implement any interface, then a CGLIB-based proxy will be created. This is the simplest scenario because JDK proxies are based on interfaces and no interface means there is no possibility of proxying using JDK.
If the proxyTargetClass property of the ProxyFactoryBean is set to true, then a CGLIB-based proxy will be created. Such a specification makes sense and follows the law of least astonishment (guaranteeing the consistency of the setting). Even when the proxyInterfaces property of the ProxyFactoryBean is set to one or more fully qualified interface names, and the proxyTargetClass property is set to true will still actually use a CGLIB-based proxy.
If the proxyInterfaces property of the ProxyFactoryBean is set to one or more fully qualified interface names, a JDK-based proxy will be created. The created proxy will implement all the interfaces specified in the proxyInterfaces attribute; if the target class implements all the interfaces specified in the proxyInterfaces attribute and some additional interfaces, the returned proxy will only implement the specified interfaces and not those additional interfaces .
If the proxyInterfaces property of the ProxyFactoryBean is not set, but the target class implements one (or more) interfaces, then the ProxyFactoryBean will automatically detect that the target class has implemented at least one interface, and a JDK-based proxy will be created. The interfaces that are actually proxied will be all the interfaces implemented by the target class; in fact, this is the same as listing every interface implemented by the target class in the proxyInterfaces property. However, this will significantly reduce the amount of work and the possibility of typos.