java Spring 多个应用程序上下文 vs 单个应用程序上下文
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10926449/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Spring multiple application contexts vs single application context in an ear
提问by Cris
I have inherited an app which is packaged as ear file that has inside
我继承了一个应用程序，它被打包成一个耳朵文件，里面有
- ear :
-APP-INF/lib (persitence.jar - hibernate+spring ... etc)
-war (web-services)
-jar (mdb)
-jar (mdb)
As I studied the app noticed that each module has inside the jar creates it's own Spring application context that is loaded on runtime.
当我研究应用程序时注意到，jar 中的每个模块都创建了它自己的 Spring 应用程序上下文，该上下文在运行时加载。
It works ok but it would not be better to have only one application context ? I wonder what are the benefits and drawback which this structure compared to the one where it is only an single application context used ?
它工作正常，但只有一个应用程序上下文不是更好吗？我想知道这种结构与仅使用单个应用程序上下文的结构相比有哪些优点和缺点？
To be more clear on runtime there are 3 application context roots loaded.It is not only that there are more application context files
为了在运行时更清楚，加载了 3 个应用程序上下文根。不仅有更多的应用程序上下文文件
Thanks
谢谢
回答by Tom
first of all: are you sure it isn't the same application context everywhere ? have you tested this ?
首先：你确定它不是到处都是相同的应用程序上下文吗？你测试过这个吗？
if they are all seperate: the advantage is that those application contexts are shielded from eachother, which you could call loose coupling, which is a good thing; one can't influence the other, it keeps things clearer for the programmer. the disadvantage is, it might be harder to access one application context from the other, but you can always find a way around this.
如果它们都是独立的：优点是这些应用程序上下文相互屏蔽，您可以称之为松散耦合，这是一件好事；一个不能影响另一个，它让程序员更清楚。缺点是，从另一个应用程序上下文访问一个应用程序上下文可能更难，但您总能找到解决方法。
回答by Japan Trivedi
If the application very large then the application context of different modules is easy to manage and it doesn't create any overhead. At the time when application is up all the context xml files will be combined.
如果应用程序非常大，那么不同模块的应用程序上下文很容易管理并且不会产生任何开销。当应用程序启动时，所有上下文 xml 文件将被合并。
And I will also prefer to maintain separate application context files for separate set of configurations eg. security, datasource, aop etc. should be placed in separate context files.
而且我也更愿意为单独的配置集维护单独的应用程序上下文文件，例如。安全性、数据源、aop 等应放在单独的上下文文件中。
When the application is small then you can go for single application context file for whole application. Otherwise different application context for different modules is easy to manage in case when you need to do some changes in any one of them. If you combine all of them then it will be very difficult to do any changes in that.
当应用程序很小时，您可以为整个应用程序使用单个应用程序上下文文件。否则，不同模块的不同应用程序上下文很容易管理，以防您需要对其中任何一个进行一些更改。如果您将所有这些结合起来，那么将很难对其进行任何更改。
Hope this helps you. Cheers.
希望这对你有帮助。干杯。
回答by mprabhat
Few points against single application-context file that I can think of:
我能想到的针对单个应用程序上下文文件的几点：
- One file will get huge and it will be maintenance nightmare.
- Developers of each component will modify,update same file can lead to errors.
- Changes in one component will lead to changes in one centralized file, again may lead to issues.
- It gives every component developer "Separation of Concern", they don't have to see, know others work while carrying out there task.
- 一个文件会变得很大，这将是维护的噩梦。
- 每个组件的开发者都会修改，更新同一个文件会导致错误。
- 一个组件的变化会导致一个集中文件的变化，同样可能会导致问题。
- 它为每个组件开发人员提供了“关注点分离”，他们在执行那里的任务时不必看到、了解其他人的工作。
回答by bhantol
I stumbled on this thread which seeking a solution for multi-tenant application. Most articles are just about datasource (Spring HotSwapable datasource targets) etc but what you have is a separate context at the war level.
我偶然发现了这个寻求多租户应用程序解决方案的线程。大多数文章只是关于数据源（Spring HotSwapable 数据源目标）等，但您拥有的是War级别的单独上下文。
This gives me another idea of bundling my application in a way that makes it multi-tenant. If the wars are skinny just to inject special runtimes and provide additional context path qualifies this may work for a large multi-tenant application. Common classes will be loaded at the EAR level and application contexts per war. I guess this should be ok for small number of tenants.
这让我有了另一种想法，即以一种使其成为多租户的方式捆绑我的应用程序。如果War只是为了注入特殊的运行时并提供额外的上下文路径，这可能适用于大型多租户应用程序。公共类将在每个War的 EAR 级别和应用程序上下文中加载。我想这对于少数租户来说应该没问题。
