我目前正在设计应用程序配置。 应用程序将利用 Spring,并且它可以仅使用其 XML bean 上下文配置,但要求设置为在其旁边有一些分层 XML 配置。这将使用 applicationContext 中指定的 bean。
例如,给定以下内容:
applicationContext.xml:
<bean id="A" class="" init-method="">
<property name="namespace" value="${namespace}"/>
</bean>
<bean id="B" class="" init-method="">
<property name="restTemplate" ref="restTemplate"/>
</bean>
config.xml:
<configuration>
<consumers-config>
<consumers>
<!--A consumer should be first defined in another configuration file-->
<consumer bean-name="A">
<name>A-1</name>
<namespace>...</namespace>
</consumer>
<consumer bean-name="B">
<name>B-1</name>
</consumer>
</consumers>
</consumers-config>
<works>
<work name="1">
<consumers>
<consumer>A-1</consumer>
<consumer>B-1</consumer>
</consumers>
</work>
</works>
<configuration>
从上面可以看出,config.xml 大量引用了 applicationContext,从而有效地使后者成为依赖。
分层配置的必要性是允许用户修改此类配置,而无需接触 applicationContext。
这是一个理想的情况吗?我应该考虑哪些最佳实践?换句话说,解决此类问题的最佳方法是什么?
最佳答案
这是否是一个可用的解决方案在很大程度上取决于您的情况和您的用户。用户直接编辑applicationContext.xml会有什么问题?如果只是为了在文件中进行组织,以便您知道在哪个文件中可以找到哪些设置,并且您自己的特殊 XML 语法更具可读性,那么您也可以简单地使用 <import>
标签以包含另一个可由用户编辑的 spring xml 配置文件。您还可以create your own XML namespace这样您就可以在此文件中使用您自己的 XML 格式,从而可能使该文件更具可读性。
但是,如果您分离这些文件的动机是这些文件可以独立维护,并且不理解 applicationContext.xml 的用户可以编辑该文件,甚至如果用户可以编辑该文件,则会出现安全问题,那么这个解决方案就有问题了。当然,您可以通过指定一个显式的 bean 列表来解决这个问题,这些 bean 类似于 config.xml 文件编辑器可用的接口(interface),并对 XML 文件运行验证以确保仅使用您的命名空间(可能不包含可能存在安全风险的标签),并验证只有 Bean 名称是在 API 中发布的引用,但这会使维护变得更加困难,并增加安全问题的风险。然而,在这种情况下,要提出更好的解决方案,需要更深入地了解您的实际需求以及您想要实现的目标。
关于java - 连接到 Bean 配置的分层配置,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37432454/