The AbstractAutoProxyCreator's wrapIfNecessary method does not expect to be overridden by subclasses, whereas getAdvicesAndAdvisorsForBean and shouldSkip expect to be overridden by subclasses even more.
The logic of SeataAutoDataSourceProxyCreator's override of wrapIfNecessary can be done entirely in getAdvicesAndAdvisorsForBean and shouldSkip.
For example, the logic in the red box below can be done entirely in shouldSkip
Meanwhile, the following logic for SeataDataSourceProxy creation can be done entirely in getAdvicesAndAdvisorsForBean, passing the created proxy to SeataAutoDataSourceProxyAdvice via the constructor
This also means that the existence of the DataSourceProxyHolder is unnecessary
2条答案
按热度按时间pobjuy321#
The SeataAutoDataSourceProxyCreator inherits from AbstractAutoProxyCreator, and the reason for not wanting to override wrapIfNecessary is what?
fumotvh32#
getAdvicesAndAdvisorsForBean
This is no problem from the point of view of the implementation of the function, but Spring AOP design wrapIfNecessary's original intention is not to allow subclasses to inherit it directly, but through the subclasses to implement some extension points, such as shouldSkip and getAdvicesAndAdvisorsForBean to complete the creation of the AOP. It is understood that wrapIfNecessary is a template in the template method pattern, and inheriting directly from the template and modifying its logic seems to be a bit too brute-force.
Please correct me if I'm wrong, thanks!