4

概述
使用

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

指南要点

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

问题

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

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

问题

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

2 回答 2

3

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

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

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

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

于 2010-12-09T08:11:58.597 回答
1

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

于 2010-11-30T18:52:40.337 回答