假设我们已经构建了一个带有 DI 框架的系统，该系统运行良好。该系统当前使用 JMS 与我们未维护的其他系统“对话”。我们的大多数客户都喜欢 JMS 方法并根据我们的规范使用它。执行所有消息传递的组件通过 Spring 注入(inject)到应用程序的其余部分。
现在我们遇到一个客户无法实现 JMS 解决方案并希望使用另一种消息传递技术的情况。这不是问题，因为我们可以简单地使用该技术实现消息服务并将其注入(inject)应用程序的其余部分。
但是我们应该如何处理配置的部署和维护呢？由于该应用程序使用 Spring，我可以想象检查我对该应用程序的所有配置，系统管理员可以启动该应用程序并传递 DI XML 文件的名称以指定应加载哪个配置。但是……就是感觉不对。是否有针对此类情况的解决方案？您使用的最佳实践是什么？我什至可以想象更复杂的场景，其中不仅仅包含一个服务替换......
非常感谢!
最佳答案
另一个建议:如何将您的 spring 配置分成两部分:一个发送给每个人的公共(public)文件，以及一个包含不同 bean 定义的特定于部署的文件。所以你可以:
applicationCommon.xml
deploymentJMS.xml
deploymentOtherMessaging.xml
deploymentDifferentAgainMessaging.xml
然后，当您的系统管理员部署时，他们会根据场景选择一个部署???.xml 文件并将其放入配置目录
您的应用程序将配置为使用通配符表达式来加载 applicationCommon.xml 文件和配置目录中的任何其他 xml 文件，同时使用它们来构建应用程序上下文(无需特别关心它们是哪些实际文件)。
不同的部署 XML 文件将存在于源代码控制中，系统管理员不需要任何详细知识，只要知道他们始终部署适合该场景的指定部署 ???.xml 文件即可。
(如果它是一个 Web 应用程序，您可能希望将“config”目录与 Web 应用程序本身分开，以便重新部署该应用程序不会覆盖特定于部署的配置)
当然，这种部署都可以编写脚本，以便通过命令行参数选择正确的文件，例如......
关于java - 依赖注入(inject) : How to maintain multiple configurations?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1707802/