Spring上下文文件的组织和最佳实践

Question

我们在项目中开始使用Spring框架。在熟悉基本功能（IoC）后，我们也开始使用Spring AOP和Spring Security。

问题是，我们现在有超过8个不同的上下文文件，并且我感觉我们没有为这些文件及其角色的组织付出足够的思考。随着项目的发展，新文件被引入。我们有不同的上下文文件用于：元数据、AOP、授权、服务、Web资源（这是一个RESTful应用程序）。因此，当开发人员想要添加新的bean时，不总是清楚应该将其添加到哪个文件中。我们需要方法论。

问题是：

Spring文件的组织是否有最佳实践？

上下文文件是否应该封装层（DAL、业务逻辑、Web）或使用案例？还是流程？

- LiorH

Answer 1

如果你的项目还比较早期，我强烈建议您考虑注解驱动配置。转换为注解后，我们只需要一个包含定义的xml文件，而且它非常小，这是一个大型项目。注解驱动配置将重点放在实现上，而不是xml上。它还或多或少地消除了Spring“bean名称”这个相当冗余的抽象层。原来bean名称主要是由于xml而存在（在注解配置中仍然存在，但在大多数情况下是无关紧要的）。在进行这个切换之后，大项目中每个人都100%同意它更好，并且我们还有相当充分的证据表明这是一个更具生产力的环境。

我真心推荐任何使用Spring的人转向注解。也可以混合使用它们。如果您需要过渡性建议，我想在Stack Overflow上询问会很容易 ;)

- krosenvold

---

非常好的建议。不幸的是，我仍然被困在XML模式中。老习惯难改。另一个典型的好评论。我期待着你的帖子。 - duffymo

谢谢 ;) 如果有人问，我认为我应该能够展示你可以很容易地开始使用注释，并且几乎没有痛苦。这真的是一种愉悦的工作方式。它为Java和Spring注入了新生命。 - krosenvold

我认为注解会污染源文件。此外，您需要修改源代码才能更改配置（例如，将bean替换为模拟对象以进行快速测试）。我是否遗漏了什么？也许我需要把这个当作一个问题来问。 - kgiannakakis

是的，你错过了所有有趣的部分。在注解驱动的环境中如何组织测试确实是一个不同的问题，而不是如何转换为注解；）测试甚至更加美丽。 - krosenvold

谢谢，我会研究你建议的基于注解的策略。 - LiorH

Answer 2

从applicationContext.xml开始，当有很多bean有共同点时应该进行分离。

以下是我目前正在处理的应用程序中可能设置的一些想法：

在服务器上：

- applicationContext.xml - securityContext.xml - schedulingContext.xml - dataSourcecontext.xml - spring-ws-servlet.xml（与Spring Web Services相关的bean）

对于GUI客户端，由于此项目有几个，因此有一个带有共享上下文文件的文件夹，并且每个客户端都有自己的上下文文件夹。共享上下文文件：

- sharedMainApplicationContext.xml - sharedGuiContext.xml - sharedSecurityContext.xml

应用程序特定文件：

- mainApplicationContext.xml和 - guiContext.xml和 - commandsContext.xml（菜单结构） - sharedBusinessLayerContext.xml（用于连接服务器的bean）

- Domchi

Answer 3

Spring上下文文件包含bean的定义，因此我认为最好遵循面向对象的原则，并将它们结构化地与您在包中组织类的方式相同。通常我们创建包来封装一组共同解决特定问题的类。一个包通常封装了一个水平层（数据库层、中间件、业务逻辑或其中的一部分）。有时一个包会包含与水平层对应的类（如您所提到的用例或流程）。一般而言，我建议为每个包或一组包创建一个上下文文件。当您添加新的bean时，请将其添加到与类所在包相对应的上下文文件中。

当然，这并不应该是非常严格的规则，因为可能存在其他实践方式更为有益的情况。

- kgiannakakis

---

你会将AOP或授权上下文与业务逻辑分开吗？ - LiorH

我更喜欢有一个security.xml文件来保存这些bean。在小到中等规模的项目中，我认为这样做更好。也许对于大型项目来说，这不太合适。 - kgiannakakis

Answer 4

我会遵循Spring的建议，将上下文文件放置在META-INF/spring中，如Spring Roo文档所述。一般来说，我建议尝试使用roo并遵循他们的项目结构和布局。 示例

src/
+-- main/
|   +-- java/
|   \-- resources/
|       +-- META-INF/
|       |   \-- spring/                    ‹ normal spring context files
|       |       +-- context.xml
|       |       \-- context-services.xml
|       \-- other files
|
+-- test/
|   +-- java/
|   \-- resources/
|       +-- META-INF/
|       |   \-- spring/                    ‹ context files for testing
|       |       +-- context-test.xml
|       |       \-- context-dao-test.xml   
|       \-- other files
|
\-- pom.xml

Spring XML vs annotations

这个话题有很多好的文章，但我想打破一个常见的误解，因为两种方法都有其优点：如果你想将配置与实际实现分离，使用XML会更容易，但你也可以通过注释实现相同的效果，就像krosenvold所说的那样。然而，在使用XML配置文件时，只有在需要直接引用bean时才需要指定bean名称。您始终可以按名称或按类型使用auto-wiring。

唯一重要的是，您应该在整个项目中保持一致，或者在可能的情况下跨公司项目保持一致。

- Kariem

Answer 5

我发现我按层次进行拆分。

当我为每个层编写单元测试时，我会使用与测试相关的值来覆盖生产环境上下文。

- duffymo

Answer 6

yep - 将其中的 bean 拆分成类似的角色。至于注解，我认为它们可能在事务定义方面扮演一些小角色，但除此之外，它们只会永久地绑定您的代码，就好像您直接在每个地方添加 Spring（或任何其他第三方）参考一样。对我来说，注解=快捷方式和技术债务。它们无法在外部进行配置，因此重构或解除您的代码不是微不足道的，并且限制了重用性。给定的 bean 与其注释的依赖项和配置永远相连，因此无法在不同的项目/进程中同时使用不同的布线和配置。 以上仅代表我的个人观点。

- Jase

Answer 7

将配置文件拆分成独立的文件对于我的测试非常有用。在小型项目中，我将Spring安全配置放入“securityContext.xml”，将其余bean放入“applicationContext.xml”。然后，在运行集成测试时，只需选择是否包含securityContext.xml即可轻松启用或禁用安全性。这几乎类似于AOP，您可以通过选择是否包含特定文件来为应用程序添加更多功能。

- brd6644