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

如果您还处于项目的早期阶段,我强烈建议您查看注释驱动的配置。转换为注释后,我们只有一个带有定义的xml文件,它非常小,这是一个大型项目。注释驱动的配置将重点放在实现上,而不是xml上。它还或多或少地删除了相当冗余的抽象层,即spring的“bean名称”。事实证明,bean名称大部分都存在 xml(bean名称仍然存在于注释配置中,但在大多数情况下并不相关)。在完成这项工作后,每个人都100%同意这是一个大项目 大量 更好,我们也有相当好的证据表明这是一个更具生产力的环境。

我真的很推荐你 任何人

从applicationContext.xml开始,当有很多bean有共同点时,将其分开。

为了让您了解可能的设置,在我目前正在开发的应用程序中,以下是我在服务器中的内容:

• applicationContext.xml
• schedulingContext.xml
• dataSourcecontext.xml

对于GUI客户机,由于此项目有多个,因此有一个文件夹包含共享的上下文文件,除此之外,每个客户机都有自己的上下文文件夹。共享上下文文件:

• sharedGuiContext.xml
• sharedSecurityContext.xml

特定于应用程序的文件:

• mainApplicationContext.xml和
• guiContext.xml和
• commandsContext.xml(菜单结构)
• sharedBusinessLayerContext.xml(用于连接到服务器的bean)

当然,这不应该是一个非常严格的规则,因为在某些情况下,遵循另一种做法可能是有益的。

我发现我把它们按层分开。

是的-为其中的bean拆分类似的角色。至于注释,我相信它们“可能”起着很小的作用,可能是在事务定义中,但否则它们会永远绑定您的代码,您也可以在任何地方直接添加spring(或任何其他第三方)引用。对我来说,注释=捷径和技术债务。它们不是外部可配置的,因此重新布线或取消代码布线并不容易,并限制了重用。一个给定的bean永远被它的注释依赖项和配置所束缚,因此不能被多个项目/进程同时使用不同的连接和配置。 只要我的2美分。

我将遵循spring的建议,将上下文文件放在 META-INF/spring 如中所述 Spring Roo documentation . 总的来说,我建议尝试一下 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

关于这个主题有很多好文章,但我想打破一个常见的误解,因为这两种方法都有各自的优点:如果您想将配置与实际实现分开,使用XML会更容易,但使用注释也可以实现同样的效果,如下所示 krosenvold said . 但是,当使用XML配置文件时,如果必须直接引用bean,则只需要bean名称。你可以随时使用 auto-wiring 按名称或按类型。

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

在测试方面,将配置分解成不同的文件对我很有用。在一个小项目中,我将把Spring安全配置放在“securityContext.xml”中,其余bean放在“applicationContext.xml”中。然后在运行集成测试时,通过选择是否包含securityContext.xml,很容易启用或禁用安全性。这在某种程度上类似于AOP,通过选择是否包含特定文件,您可以向应用程序添加更多功能。