弹出多个应用程序上下文与单个应用程序上下文

Question

我继承了一个打包为内部

的ear文件的应用程序

 - ear :
        -APP-INF/lib (persitence.jar - hibernate+spring ... etc)
        -war (web-services)
        -jar (mdb)
        -jar (mdb)

当我研究应用时注意到每个模块都在jar内部创建了自己的Spring应用程序上下文，该上下文在运行时加载。

它工作正常，但只有一个应用程序上下文不是更好吗？  我想知道这个结构与仅使用单个应用程序上下文的结构相比有什么好处和缺点？

为了在运行时更清楚，加载了3个应用程序上下文根。不仅有更多的应用程序上下文文件

由于

Answer 1

首先：你确定它到处都不是同一个应用程序环境吗？你试过这个吗？

如果他们都是分开的： 优点是那些应用程序上下文彼此屏蔽，你可以称之为松散耦合，这是一件好事;一个人不能影响另一个，它让程序员更清楚。 缺点是，从另一个应用程序上下文访问可能更难，但你总能找到解决方法。

Answer 2

如果应用程序非常大，那么不同模块的应用程序上下文很容易管理，并且不会产生任何开销。在应用程序启动时，将组合所有上下文xml文件。

我还希望为单独的配置集维护单独的应用程序上下文文件，例如。安全性，数据源，aop等应放在单独的上下文文件中。

当应用程序很小时，您可以为整个应用程序寻找单个应用程序上下文文件。否则，当您需要对其中任何一个进行某些更改时，可以轻松管理不同模块的不同应用程序上下文。如果将所有这些组合在一起，则很难对其进行任何更改。

希望这会对你有所帮助。欢呼声。

Answer 3

我能想到的单个应用程序上下文文件几点：

1. 一个文件会变得很大，这将是维护的噩梦。
2. 每个组件的开发人员都会修改，更新同一个文件会导致错误。
3. 一个组件的更改将导致一个集中文件发生更改，同样可能导致问题。
4. 它给每个组件开发人员“分离关注”，他们没有必要看到，知道其他人在执行任务时工作。

Answer 4

我偶然发现了这个寻求多租户应用解决方案的线程。大多数文章只是关于数据源（Spring HotSwapable数据源目标）等，但你所拥有的是战争级别的单独上下文。

这让我有了另一种想法，即以一种使其成为多租户的方式捆绑我的应用程序。 如果战争只是为了注入特殊的运行时并且提供额外的上下文路径限定，那么这可能适用于大型多租户应用程序。公共类将在每次战争的EAR级别和应用程序上下文中加载。我想这对少数租户来说应该没问题。