若使用 Spring IoC 容器（ApplicationContext或BeanFactory）作为你的业务对象（你也应该这么做！），你会想使用 Spring AOP FactoryBean的一种。 工厂 bean 引入了中间层，让它创建不同类型的对象。
在Spring创建 AOP 代理的基本方式是使用 org.springframework.aop.framework.ProxyFactoryBean。这可以完全控制pointcuts、使用的任何通知和他们的顺序。但若不需要这样的控制，也有更简单的选择。
1 基础
ProxyFactoryBean，类似其他 Spring 的FactoryBean实现，引入了中间层。
若你定义了名为 foo 的ProxyFactoryBean，则引用 foo 的对象不会看到ProxyFactoryBean实例本身，而是在ProxyFactoryBean中实现的 getObject()创建的对象。该方法创建了一个包装目标对象的 AOP 代理。
使用ProxyFactoryBean或其他 IoC-aware 类创建 AOP 代理的最大好处之一是advices和pointcuts也可以由 IoC 管理。这是一个强大的功能，使某些方法很难用AOP 实现的开启了新途径。例如，advice本身可能引用应用对象（不仅是目标对象，该对象应在任何 AOP 框架中都可用），从而受益于DI提供的所有可插拔性。
2 JavaBean属性
与大多数FactoryBean实现类似， ProxyFactoryBean类本身就是一个JavaBean。
其属性用于：
- 指定要代理的目标
- 指定是否使用 CGLIB
一些关键属性是从 org.springframework.aop.framework.ProxyConfig （Spring所有 Aop 代理工厂的父类） 继承的。这些关键属性包括：
- proxyTargetClass 如果要代理目标类，而不是目标类的接口，则为 true。如果此属性值设置为true，则创建 CGLIB 代理
- optimize 控制是否将主动优化应用于通过 CGLIB 创建的代理。除非你完全了解相关的 AOP 代理如何处理优化，否则您不应轻率地使用此设置。仅用于 CGLIB 代理，对 JDK 动态代理无影响。
- frozen 如果代理配置被冻结，则不再允许更改配置。这既是一种轻微的优化，也是在不希望调用者在创建代理后（通过建议的接口）操纵代理时，这些情况是有用的。默认值false，即允许更改（比如添加额外advice）。
- exposeProxy
确定当前代理是否应在
ThreadLocal暴露，以便目标可以访问该代理。如果目标需要获取代理并将暴露的 Proxy 属性设置为true，则目标可以使用 AopContext.当前普罗西 （） 方法。
ProxyFactoryBean其他属性包括：
- proxyInterfaces 字符串接口名称的数组。若不提供此，则使用目标类的 CGLIB 代理
- interceptorNames
要应用的Advisor、拦截器或其他建议名称的字符串数组。顺序非常重要，首先先到先得。也就是说，列表中的第一个拦截器是能够拦截调用的第一个拦截器。
这些名称是当前工厂中的bean名称，包括来自祖先工厂的bean名称。你不能在这里使用bean引用， 因为这样做会导致
ProxyFactoryBean忽略了推荐的单例设置。 可以用*附加拦截器名称。这样做会导致应用所有advisor beans与名称，开始与*应用前的部分。 - singleton
工厂是否应该返回单例的对象，无论
getObject()调用频率如何，几个FactoryBean实现都提供这样的方法。默认值为true。如果你想使用有状态的advice，使用prototype 类型的advices以及false的singleton值。
3 JDK和CGLIB代理
ProxyFactoryBean如何选择为特定目标对象（将代理）创建基于 JDK 的代理或基于 CGLIB 的代理。
ProxyFactoryBean在创建基于 JDK 或 CGLIB 的代理方面的行为在Spring的 1.2.x 版本和 2.0 版本之间发生了变化。ProxyFactoryBean现在在自动检测接口方面表现出与TransactionProxyFactoryBean类类似的语义。
如果要代理的目标对象类别（以下简称目标类）不实现任何接口，则创建基于 CGLIB 的代理。这是最简单的方案，因为 JDK 代理是基于接口的，没有接口意味着 JDK 代理甚至是不可能的。您可以插入目标豆，并通过设置拦截器命名属性来指定拦截器列表。请注意，即使代理工厂豆的代理目标类属性被设置为虚假，也创建基于 CGLIB 的代理。（这样做是没有意义的，最好从豆的定义中删除，因为它充其量是多余的，而且，在最坏的情况下是令人困惑的。
