我目前正在设计一个应用程序配置。应用程序将利用Spring,并且它只能使用它的XML上下文配置,但是需求被设置成在它旁边有一些层次化的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配置。
这是理想的情况吗?是否有我应该考虑的最佳做法?换句话说,处理这个问题的最佳方法是什么?
发布于 2016-06-01 08:40:26
这是否是一个可用的解决方案在很大程度上取决于您的情况和您的用户。用户直接编辑applicationContext.xml会有什么问题呢?如果它仅用于文件中的组织,以便您知道可以在哪个文件中找到哪些设置,并且您自己的特殊XML语法更具可读性,那么您也可以简单地使用<import>标记来包含另一个可以由用户编辑的spring配置文件。您还可以在这个文件中使用自己的创建自己的XML命名空间格式,从而可能使该文件更具可读性。
但是,如果您分离这些文件的动机是可以独立维护这些文件,并且不了解applicationContext.xml的用户可以编辑该文件,或者如果用户可以编辑该文件,那么这个解决方案就是一个问题。当然,您可以通过指定一个明确的bean列表来解决这个问题,这些bean就像您的config.xml文件的编辑器可以使用的接口一样,并在XML文件上运行验证,以确保只使用您的命名空间(它可能不包含可能存在安全风险的标记),还可以验证只有bean名称是在您的API中发布的引用,但它将使维护变得更加困难,并增加安全问题的风险。然而,要想在这种情况下提出更好的解决方案,就需要更深入地了解您的需求实际上是什么以及您试图实现什么。
https://stackoverflow.com/questions/37432454
复制相似问题