6.4. 使用ProxyFactoryBean创建 AOP 代理
最后更新于
这有帮助吗？
最后更新于
这有帮助吗？
如果您将 Spring IoC 容器（ApplicationContext或BeanFactory）用于您的业务对象（您应该这样做！），您希望使用 Spring 的 AOP FactoryBean实现之一。（请记住，工厂 bean 引入了一个间接层，让它创建不同类型的对象。）
Spring AOP 支持也在幕后使用了工厂 bean。 |
在 Spring 中创建 AOP 代理的基本方法是使用 org.springframework.aop.framework.ProxyFactoryBean. 这可以完全控制切入点、任何适用的切面及其顺序。但是，如果您不需要此类控制，则可以使用更简单的选项。
6.4.1. 基本
与其他 SpringFactoryBean实现一样，ProxyFactoryBean引入了间接级别。如果定义名为 foo 的 ProxyFactoryBean，则引用 foo 的对象不会看到 ProxyFactoryBean 实例本身，而是看到由 ProxyFactoryBean 中的getObject()方法的实现创建的对象。此方法创建一个包装目标对象的 AOP 代理。
使用一个ProxyFactoryBean或另一个 IoC 感知类来创建 AOP 代理的最重要的好处之一是切面和切入点也可以由 IoC 管理。这是一个强大的特性，可以实现其他 AOP 框架难以实现的某些方法。例如，一个通知本身可能引用应用程序对象（除了目标，它应该在任何 AOP 框架中都可用），受益于依赖注入提供的所有可插入性。
6.4.2. JavaBean 属性
与 Spring 提供的大多数FactoryBean实现一样， ProxyFactoryBean该类本身就是一个 JavaBean。它的属性用于：
指定要代理的目标。
指定是否使用 CGLIB（稍后描述，另请参见）。
一些关键属性继承自org.springframework.aop.framework.ProxyConfig （Spring 中所有 AOP 代理工厂的超类）。这些关键属性包括：
proxyTargetClass：true：如果要代理目标类，而不是目标类的接口。如果此属性值设置为true，则创建 CGLIB 代理（另请参阅）。
optimize：控制是否对通过 CGLIB 创建的代理应用积极优化。除非您完全了解相关的 AOP 代理如何处理优化，否则您不应轻率地使用此设置。这目前仅用于 CGLIB 代理。它对 JDK 动态代理没有影响。
frozen：如果代理配置是frozen，则不再允许更改配置。这对于轻微的优化和在创建代理后不希望调用者能够操纵代理（通过Advised 接口）的情况都很有用。此属性的默认值为 false，因此允许更改（例如添加额外的切面）。
exposeProxy：确定当前代理是否应该在ThreadLocal中公开， 以便目标可以访问它。如果目标需要获取代理并且exposeProxy属性设置为true，目标可以使用该 AopContext.currentProxy()方法。
ProxyFactoryBean其他属性具体包括以下内容：
proxyInterfaces:String类型的接口名称数组。如果未提供，则使用目标类的 CGLIB 代理（但另请参阅）。
interceptorNames：要应用的 、拦截器或其他切面名称的String数组。Advisor订购很重要，先到先得。也就是说列表中的第一个拦截器是第一个能够拦截调用的。
这些名称是当前工厂中的 bean 名称，包括来自祖先工厂的 bean 名称。您不能在此处提及 bean 引用，因为这样做会导致 ProxyFactoryBean忽略通知的单例设置。
您可以附加一个带有星号 ( *) 的拦截器名称。这样做会导致应用名称以要应用的星号之前的部分开头的所有Advisor bean。中找到使用此功能的示例。
单例：工厂是否应该返回单个对象，无论getObject()方法被调用的频率如何。几个FactoryBean实现提供了这样的方法。默认值为true。如果你想使用有状态的切面——例如，对于有状态的 mixins——使用原型切面和 false.
6.4.3. 基于 JDK 和 CGLIB 的代理
本节是关于如何ProxyFactoryBean 选择为特定目标对象（将被代理）创建基于 JDK 的代理或基于 CGLIB 的代理的权威文档。
在 Spring 的 1.2.x 和 2.0 版本之间，创建基于 JDK 或 CGLIB 的代理 ProxyFactoryBean的行为发生了变化。现在ProxyFactoryBean在自动检测接口方面表现出与TransactionProxyFactoryBean类相似的语义 。
如果要代理的目标对象的类（以下简称目标类）没有实现任何接口，则创建基于CGLIB的代理。这是最简单的场景，因为 JDK 代理是基于接口的，没有接口意味着 JDK 代理甚至是不可能的。您可以插入目标 bean 并通过设置interceptorNames属性来指定拦截器列表。请注意，即使 ProxyFactoryBean的proxyTargetClass属性已设置为false，也会创建基于 CGLIB 的代理。（这样做毫无意义，最好从 bean 定义中删除，因为它充其量是多余的，最坏的情况是令人困惑。）
如果目标类实现一个（或多个）接口，则创建的代理类型取决于ProxyFactoryBean.
如果 ProxyFactoryBean的proxyTargetClass属性已设置为true，则创建基于 CGLIB 的代理。这是有道理的，并且符合最小意外原则。即使ProxyFactoryBean 的proxyInterfaces属性 已设置为一个或多个完全限定的接口名称，该proxyTargetClass属性设置为true这一事实也会导致基于 CGLIB 的代理生效。
如果 ProxyFactoryBean的proxyInterfaces属性已设置为一个或多个完全限定的接口名称，则会创建一个基于 JDK 的代理。proxyInterfaces 创建的代理实现了属性中指定的所有接口。如果目标类碰巧实现了比proxyInterfaces属性中指定的接口多得多的接口，那很好，但是返回的代理不会实现这些额外的接口。
如果 ProxyFactoryBean 的 proxyInterfaces 属性尚未设置，但目标类确实实现了一个（或多个）接口，则 ProxyFactoryBean 会自动检测目标类确实至少实现了一个接口，并且基于 JDK 的代理被建造。实际被代理的接口是目标类实现的所有接口。实际上，这与向 proxyInterfaces 属性提供目标类实现的每个接口的列表相同。然而，它的工作量明显减少，并且不太容易出现印刷错误。
6.4.4. 代理接口
考虑一个简单的例子ProxyFactoryBean。此示例涉及：
被代理的目标 bean。这是personTarget示例中的 bean 定义。
Advisor和 Interceptor用于提供切面。
一个 AOP 代理 bean 定义，用于指定目标对象（personTargetbean）、要代理的接口以及要应用的切面。
以下清单显示了该示例：
请注意，该interceptorNames属性需要一个 String列表，其中包含当前工厂中拦截器或Advisor的 bean 名称。您可以在返回之前、之后使用Advisor、拦截器和抛出切面对象。Advisor的顺序很重要。
您可能想知道为什么该列表不包含 bean 引用。这样做的原因是，如果ProxyFactoryBean 的单例属性设置为false，它必须能够返回独立的代理实例。如果任何Advisor本身是原型，则需要返回一个独立的实例，因此必须能够从工厂获取原型的实例。持有参考资料是不够的。
前面显示的personbean 定义可以用来代替Person实现，如下所示：
同一个 IoC 上下文中的其他 bean 可以表达对它的强类型依赖，就像普通的 Java 对象一样。以下示例显示了如何执行此操作：
此示例中的PersonUser类公开了一个类型为Person 的属性。就它而言，可以透明地使用 AOP 代理来代替“真实”的人员实现。但是，它的类将是一个动态代理类。可以将其转换为Advised接口（稍后讨论）。
您可以使用匿名内部 bean 隐藏目标和代理之间的区别。只是ProxyFactoryBean定义不同。该切面仅出于完整性考虑。以下示例显示了如何使用匿名内部 bean：
使用匿名内部 bean 的优点是只有一个类型的对象Person。如果我们想要阻止应用程序上下文的用户获取对不切面的对象的引用，或者需要避免 Spring IoC 自动装配的任何歧义，这很有用。可以说，还有一个优点是ProxyFactoryBean定义是独立的。但是，有时能够从工厂获得不切面的目标实际上可能是一种优势（例如，在某些测试场景中）。
6.4.5. 代理类
如果您需要代理一个类而不是一个或多个接口怎么办？
想象一下，在我们前面的示例中，没有 Person 接口。我们需要建议一个名为Person的类，它没有实现任何业务接口。在这种情况下，您可以将 Spring 配置为使用 CGLIB 代理而不是动态代理。为此，请将前面显示的 ProxyFactoryBean 上的 proxyTargetClass 属性设置为 true。虽然最好对接口而不是类进行编程，但在处理遗留代码时，建议未实现接口的类的能力可能会很有用。 （一般来说，Spring 不是规定性的。虽然它使应用良好实践变得容易，但它避免了强制采用特定的方法。）
如果你愿意，你可以在任何情况下强制使用 CGLIB，即使你有接口。
CGLIB 代理通过在运行时生成目标类的子类来工作。Spring 将这个生成的子类配置为将方法调用委托给原始目标。子类用于实现装饰器模式，编织在通知中。
CGLIB 代理通常应该对用户透明。但是，有一些问题需要考虑：
Final类不能被代理，因为他们无法拓展
final方法不能被切面，因为他们无法被覆写
private方法不能被切面，因为他们无法被覆写
无需将 CGLIB 添加到您的类路径中。从 Spring 3.2 开始，CGLIB 被重新打包并包含在 spring-core JAR 中。换句话说，基于 CGLIB 的 AOP 像 JDK 动态代理一样“开箱即用”。
CGLIB 代理和动态代理之间几乎没有性能差异。在这种情况下，性能不应成为决定性的考虑因素。
6.4.6. 使用“全局”Advisor
通过将星号附加到拦截器名称，所有具有与星号之前的部分匹配的 bean 名称的Advisor都将添加到Advisor链中。如果您需要添加一组标准的“全局”Advisor，这会派上用场。以下示例定义了两个全局Advisor：