16

我正在寻找使用 Spring 3 annotations 时的一些最佳实践。

我目前正在迁移到 Spring 3，从我目前所读的内容来看，我看到很多重点放在使用注释和远离 XML 配置上。

实际上，推荐的是两种样式的混合，注释涵盖不会经常更改的内容或从一次运行到下一次运行（例如@Controller，在应用程序的生命周期内将保持不变），而更改的内容和必须可配置到 XML 中（例如，邮件 smtp 地址、应用程序与之通信的 Web 服务的端点等）。

我的问题是注释应该包含什么内容以及在什么程度上？

在什么时候注释使事情变得更难而不是更容易？该技术（Spring 3）是否被完全采用以便能够做出这样的陈述，或者人们是否需要更多时间来获得它的经验然后反思这个问题？

4

5 回答 5

13

获得真正的高级信息总是很困难。

简单的教程“看我的博客，我从 Spring Source 网站上复制了 hello word 教程……现在你可以把花哨的注释放在任何地方，它解决了我们所有的问题，包括癌症和饥饿。” 不是很有用。

如果您还记得正确的弹簧芯有几个用途，其中包括：

  • 不打扰
  • 随时更改 bean 的任何实现/配置
  • 提供一个集中和受控的地方来放置您的配置

所有这些需求的注释都失败了：

  • 他们引入了与弹簧的耦合（您只能使用标准注释，但只要您至少有一个弹簧注释，这就不再适用了）
  • 您需要修改源代码并重新编译以更改 bean 实现或配置
  • 代码中到处都有注释。仅通过阅读代码或 XML 配置文件可能很难找到真正使用的 bean。

事实上，我们已经转移了关注点：

  • 我们意识到我们几乎从不提供我们服务的多个实现。
  • 我们意识到依赖 API 并没有那么糟糕。
  • 我们意识到我们不再使用 spring 来进行真正的依赖注入，主要是为了提高生产力和减少 java 代码的冗长。

所以我会在有意义的时候使用注释。当纯粹是删除样板代码时，冗长。我会注意使用 XML 配置文件来处理您想要配置的东西，即使它只是在单元测试中提供服务的存根实现。

于 2011-05-12T12:07:49.813 回答
6

正如 kunal 所指出的，我@Value用于通过 配置在外部属性文件中的属性。PropertyPlaceholderConfigurer

何时使用 xml 没有严格的规定，但我使用 xml：

  • 当 bean 不是我控制的类时
  • 当对象与基础设施或配置相关而不是与业务逻辑相关时。
  • 当该类具有一些我希望可配置但不一定通过外部化配置的原始属性时。

回应您的评论：spring 被广泛采用，但“好”和“坏”是非常主观的。甚至我的台词也不是普遍真理。XML、注释和程序化配置都是为了一个目的而存在的，每个开发者/公司都有自己的偏好。

正如我所说 - 没有严格的界限，也没有普遍的注释良好做法。

于 2011-04-21T20:25:35.807 回答
3

注释肯定是Java中“更新”编程将继续的方式。我将注解用于各种用途……例如@Scope用于 bean 的范围、@Required使依赖项成为必要、@Aspect配置建议、@Autowired使用注解进行构造函数注入。从 spring 2.5 开始，注解支持一直很好。请参阅此处了解春季教程，此处介绍了基于注释的问题。

于 2011-04-25T09:25:55.530 回答
1

我认为使用注释的两种情况可能会导致一些问题。首先，如果您想在实体中编写复杂的命名查询 (JPA)。我看到了一些实体代码示例，并问自己代码是否真的是 java 代码。程序代码中的许多元数据会降低它的可读性，从而破坏干净的代码原则。

第二个问题是 JVM 版本之间的可移植性。注释是 1.5+ 的功能。如果您的软件应该支持早期的 JVM 版本，那么您可能不会使用这些版本。

无论如何，您每次都可以毫无疑问地享受注释，并节省您的时间不更改 IDE 选项卡以检查属性是否仍然存在或输入正确等。

对于非常小的项目，如果您没有太多东西要在春季声明，您仍然可以使用 XML 版本。但是，如果你在一个巨大的项目中，如果你有 10 个 xml 配置，事情可能会很麻烦。

于 2011-05-11T20:58:41.180 回答
0

这可能对您没有多大帮助，但在工作中他们不想使用自动装配，因为它需要类路径扫描（但我认为这可以是包定义的）。所以它根据项目的大小增加了应用程序的启动时间。

于 2011-06-06T14:10:13.937 回答