Использование принципа DRY в XML

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

Моя проблема заключается в том, что A и B имеют общие параметры, хотя иногда, когда они имеют общий параметр, один или несколько подпараметров различаются.

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

Какие способы применения принципа DRY вы бы порекомендовали в этой ситуации?


person Robert Gowland    schedule 15.11.2010    source источник


Ответы (2)


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

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

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

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

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

person Martin Broadhurst    schedule 15.11.2010
comment
Я вижу, что это работает для постепенного добавления/изменения параметров или подпараметров, но как мне удалить параметр с помощью этого метода? - person Robert Gowland; 16.11.2010
comment
@Robert, у вас может быть неустановленное значение, на которое вы его установили, или другой тег для удаления, а не установка параметра. - person Martin Broadhurst; 16.11.2010

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

Пример (из руководства пользователя Ant):

<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>
person Anon    schedule 15.11.2010
comment
существуют ли какие-либо инструменты для навигации/редактирования XML-файлов этой формы? - person Robert Gowland; 15.11.2010
comment
Я бы подумал о XPath, хотя возможно, что Ant извлек функциональность (маловероятно) - person Anon; 15.11.2010