0

我继承了一个应用程序，该应用程序被打包为里面的 ear 文件

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

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

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

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

谢谢

4

4 回答 4

4

首先：你确定它不是到处都是相同的应用程序上下文吗？你测试过这个吗？

如果它们都是独立的：优点是这些应用程序上下文相互屏蔽，您可以称之为松散耦合，这是一件好事；一个不能影响另一个，它让程序员更清楚。缺点是，从另一个应用程序上下文访问一个应用程序上下文可能会更困难，但您总能找到解决此问题的方法。

于 2012-06-07T06:14:16.923 回答
3

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

而且我也更愿意为单独的一组配置维护单独的应用程序上下文文件，例如。安全、数据源、aop 等应该放在单独的上下文文件中。

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

希望这对您有所帮助。干杯。

于 2012-06-07T06:12:17.820 回答
1

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

  1. 一个文件会变得很大，这将是维护的噩梦。
  2. 每个组件的开发人员都会修改，更新相同的文件可能会导致错误。
  3. 一个组件的更改将导致一个集中文件的更改，再次可能导致问题。
  4. 它为每个组件开发人员提供了“关注点分离”，他们在执行任务时不必看到、知道其他人的工作。
于 2012-06-07T06:12:24.830 回答
0

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

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

于 2014-03-05T22:19:31.540 回答