Accepter le principe DRY en XML

Question

Nous avons un produit dans lequel chaque client dispose d'un fichier de configuration XML contenant des options et des sous-options d'interface utilisateur. Par exemple, un type d'utilisateur (appelé A) a un ensemble d'options et un autre type d'utilisateur (B) a un ensemble d'options différent. Le problème que j'ai est que A et B partagent la plupart des options, bien que parfois quand ils partagent une option, une ou plusieurs des sous-options diffèrent. Maintenant, nous obtenons des clients avec, au lieu de deux types d'utilisateurs, 30 types d'utilisateurs, et les fichiers de configuration du client sont gonflés avec la même information répétée jusqu'à 30 fois, créant un cauchemar de maintenance pour le développement.

De quelles manières recommanderiez-vous d'appliquer le principe DRY à cette situation?

Answer 1

Vous devez mettre en œuvre une forme d'héritage, tout comme l'héritage dans les langages de programmation orientés objet ou CSS, dans lequel vous commencez avec un ensemble d'options communes, puis autorisez-le à être remplacé par d'autres options dans des ensembles plus spécifiques.

Vous établissez une hiérarchie d'ensembles d'options, en commençant par le haut avec des options communes à tous les utilisateurs, puis des ensembles d'options que vous avez identifiés comme communs à plusieurs types d'utilisateurs et enfin les options spécifiques à l'utilisateur. Cela doit être représenté comme un arbre dans votre fichier de configuration XML, en donnant à chaque ensemble d'options un nom et un parent. Au bas de l'arborescence se trouvent les ensembles d'options nommés d'après les types spécifiques d'utilisateurs (As, Bs, etc.).

Dans votre programme, vous devez lire ce fichier et assembler l'arbre en mémoire. Passez ensuite de haut en bas pour collecter les options et les ignorer au fur et à mesure. Lorsque vous atteignez les options spécifiques à l'utilisateur sur les feuilles de l'arbre et effectuez les dernières remplacements, vous avez terminé. Lorsque vous factorisez vos options, vous pouvez constater que certains ensembles doivent avoir plusieurs parents, car ils combinent les options de plusieurs ensembles. Si c'est le cas, votre arbre devient un DAG, et vous devez trier topologiquement avant de le traverser. Je réalise que c'est une solution complexe, mais je peux vous assurer que c'est la façon la plus flexible de gérer plusieurs configurations qui ont des éléments communs. Je l'ai implémenté avec succès afin de configurer plusieurs sites Web de commerce électronique qui utilisaient le même back-end.

Answer 2

De la même manière que le fait Ant: chaque élément unique d'information de configuration peut recevoir un ID et être référencé via cet ID.

Exemple (à partir du 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>