Spring 注解与我的设计准则冲突

Question

概述
使用

• Spring 3.0.1（注解配置）
  • 当前配置使用 CGLib 作为代理创建者，但这不是我的偏好
  • 事务是没有任何特殊设置的注释配置
  • 所有配置都使用注释完成（@Service、@Transactional、@ManagedResource、@Inject 等）
• Hibernate 3.5（实体使用 javax.persistence 注释）

指南要点

• 每个使用@Repository 或@Service 注释的bean 都必须有一个接口
• 构造函数 DI（不需要重新配置时）
  • 构造函数具有默认可见性 (Foo(Bar bar) {...})
• Bean 字段是 final（不需要重新配置时）
  • 导致没有默认构造函数
• default 使用 final 修饰符 (final class Foo) 可见实现

问题

1. CGLib 无法代理最终类
2. CGLib 需要默认（空）构造函数
3. 某些服务需要通过 JMX 公开
4. 除非由 CGLib 代理，否则 MBean 导出器无法工作
5. 一些@Transactional@Services 是通过外观服务访问的，这需要在外观事务中包含多个服务（例如，超过 2 个应用程序组件的观察者服务）
6. 有些接口有多个实现（目前以@Qualifier 区分）
7. 未来的指导方针（或很高兴拥有功能） - 每个应用程序模块都将有 beanRefContext.xml 文件来配置其内部应用程序上下文

当我过去使用 XML 配置时，我能够强制执行我上面介绍的所有准则，但是当切换到注释时，Spring 似乎行为不端。
我小组中的开发人员更喜欢注解配置（我似乎更容易连接和编写新代码），但我注意到他们在代码中引入了各种“黑客”，以防止处理 Spring 应用程序上下文故障。

问题

1. 在使用注释配置时我应该遵循哪些最佳实践？
   • 当每个接口使用多个实现时（试图减少 @Primary 或 @Qualifier 的使用）
   • 当使用@Transactional
   • 当使用@ManagedResource
   • 结合使用上述方法时
2. 有没有办法停止使用 CGLib，保留注解配置并且仍然能够导出带有注解的 MBean？
3. 什么是保留我的大部分（最好是全部）指南的合适实施方式？

Answer 1

我想出了以下解决方案（针对问题 #2 和 #3），以便能够执行我的设计指南并继续使用基于注释的配置：

• 每个依赖项目（Maven 模块）都有自己的ApplicationContext
• 每个相关的项目应用程序上下文都在beanRefContext.xml 中定义
• 这些应用程序上下文使用 Spring 上下文层次结构机制加载到层次结构中。
  • 这一步实际上Spring并不完全支持，需要额外的work
• 由于我的应用程序是分层的，因此我可以在除 JMX 层之外的所有模块上禁用 CGLib（我可以忍受它:-)）。

上述步骤还使我能够减少 Spring 感知测试的执行时间（每个模块仅加载一个 bean 子集）。

作为一个实用指南（对于问题 #1），如果一个接口有多个实现，我将 @Primary 放置在广泛使用的一个和其他客户端上，需要另一个实现，使用 @Qualifier 连接 bean。

Answer 2

回答第 2 点） 您可以使用 AspectJ 而不是 CGLib。