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

我们已经开始在我的项目中使用Spring框架.在熟悉基本功能(IoC)之后,我们也开始使用弹簧和弹簧安全性.

问题是我们现在有超过8个不同的上下文文件,我觉得我们没有充分考虑这些文件及其角色的组织.随着项目的发展,引入了新文件.我们有不同的上下文文件:元数据,aop,授权,服务,Web资源(它是一个RESTful应用程序).因此,当开发人员想要添加新bean时,并不总是清楚他应该添加哪个文件.我们需要方法论.

问题:

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

上下文文件是否应封装层(DAL,业务逻辑,Web)或用例？还是流量？

1> krosenvold..：

---

如果您仍然在项目的早期阶段,我建议您强烈关注注释驱动的配置.转换为注释后,我们只有1个带定义的xml文件,它实际上非常小,这是一个大型项目.注释驱动配置将重点放在您的实现而不是xml上.它或多或少地删除了相当多余的抽象层,即春天的"bean名称".事实证明bean名称的存在主要是因为 xml(bean名称仍然存在于注释配置中,但在大多数情况下是无关紧要的).一致认为这是一个做一个大的项目每个人的100%,这一切换之后很多更好,我们也有相当不错的证据表明它是一个更高效的环境.

我真的推荐任何使用spring切换到注释的人.它们也可以混合使用.如果您需要过渡性建议,我想在SO上很容易询问;)

---

我认为注释会污染源文件.此外,您需要修改源以更改配置(例如,使用模拟对象替换bean以进行快速测试).我错过了什么吗？也许我需要问这个问题.

2> Domchi..：

---

从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)

3> kgiannakakis..：

---

Spring上下文文件包含bean的定义,因此我认为最好遵循OO原则并按照在包中构造类的方式构造它们.我们通常创建包来封装一组一起工作以解决特定问题的类.包通常封装水平层(数据库层,中间件,业务逻辑或其中的一部分).有时候包中包含的对应于水平层的类(如前所述的用例或流).一般来说,我建议为每个包或一组包创建一个上下文文件.添加新bean时,将其添加到与类的包对应的上下文文件中.

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