2010-11-15 3 views
3

У нас есть продукт, в котором каждый клиент имеет файл конфигурации XML, содержащий наборы параметров пользовательского интерфейса и подпараметров. Например, один тип пользователей (называть их A) имеет один набор параметров, а другой тип пользователей (B) имеет другой набор параметров.Охватывая принцип DRY в XML

Проблема заключается в том, что A и B разделяют большинство параметров, хотя иногда, когда у них есть опция, один или несколько подпараметров различаются.

Теперь мы получаем клиентов вместо двух типов пользователей, 30 типов пользователей, а файлы конфигурации клиента раздуты с той же информацией, повторяемой до 30 раз, создавая кошмар для обслуживания для разработки.

Какие способы вы бы рекомендовали применить принцип СУХОЙ к этой ситуации?

ответ

2

Вы должны реализовать форму наследования, так же, как наследование в объектно-ориентированных языков программирования или CSS, в котором вы начинаете с набором общих опций, а затем разрешить его переопределить другими опциями в более конкретных наборах.

Вы устанавливаете иерархию наборов параметров, начиная сверху, с параметрами, общими для всех пользователей, а затем наборы опций, которые вы определили как общие для многих типов пользователей, и, наконец, параметры, специфичные для пользователя. Это нужно представить в виде дерева в файле конфигурации XML, указав каждому набору параметров имя и родительский элемент. В нижней части дерева находятся наборы опций, названных в честь определенных типов пользователей (As, Bs и т. Д.).

В вашей программе необходимо прочитать этот файл и собрать дерево в памяти. Затем перемещайте его сверху вниз, собирая варианты и переопределяя их по ходу. Когда вы достигнете пользовательских параметров в листьях дерева и выполните последние переопределения, вы закончите.

Когда вы факторизуете свои параметры, вы можете обнаружить, что некоторые наборы должны иметь более одного родителя, поскольку они объединяют параметры из нескольких наборов. Если это так, ваше дерево становится DAG, и вам нужно топологически сортировать его перед тем, как вы пройдете его.

Я понимаю, что это сложное решение, но могу вас заверить, что это самый гибкий способ иметь дело с несколькими конфигурациями, которые имеют общие элементы. Я успешно его реализовал, чтобы настроить несколько веб-сайтов электронной коммерции, которые использовали один и тот же сервер.

+0

Я вижу, что это работает для постепенного добавления/изменения параметров или подпараметров, но как бы удалить эту опцию по этому методу? –

+1

@Robert, у вас может быть «не установленное» значение, на которое вы его установили, или на удаление другого тега, а не на установку параметра. –

1

Точно так же, как и Ant: каждой уникальной информации о конфигурации может быть присвоен идентификатор, и к нему можно обратиться через этот идентификатор.

Пример (из Ant user manual):

<project ... > 
    <path id="project.class.path"> 
    <pathelement location="lib/"/> 
    <pathelement path="${java.class.path}/"/> 
    <pathelement path="${additional.path}"/> 
    </path> 

    <target ... > 
    <rmic ...> 
     <classpath refid="project.class.path"/> 
    </rmic> 
    </target> 

    <target ... > 
    <javac ...> 
     <classpath refid="project.class.path"/> 
    </javac> 
    </target> 
</project> 
+0

Есть ли инструменты для навигации/редактирования XML-файлов этой формы? –

+0

Я бы подумал о XPath, хотя возможно, что Ant извлек функциональность (маловероятно) – Anon

Смежные вопросы