4 votes

Comment gérer la configuration spécifique du client

Dans le cas d'un produit utilisé par plusieurs clients, où les différents clients demandent des personnalisations différentes, tant au niveau de l'interface utilisateur que des fonctionnalités, comment prendre en compte ces changements sans encombrer le code avec du code spécifique au client ?

Existe-t-il des frameworks (pour n'importe quel langage de programmation) qui permettent de résoudre ce problème ?

Pour ajouter plus de détails, l'interface utilisateur est basée sur le Web et écrite en utilisant JSP.

3voto

FolksLord Points 674

La gestion de différentes versions d'une même application est l'une des exigences commerciales les plus difficiles à satisfaire. Il ne faut donc pas s'attendre à des cadres ouverts dans ce cas, mais chaque entreprise concernée développe son propre système pour ce genre de choses.

En ce qui concerne les modifications de la logique d'entreprise, vous bénéficierez d'une forte interface et IoC (par exemple Printemps ). Vous devez surcharger les services pour votre cas spécifique et modifier les méthodes requises, puis injecter dans IoC la version modifiée du service.

Pour ce qui est de l'interface utilisateur, c'est plus difficile car vous avez choisi JSP, qui a peu de flexibilité. Quand vous programmerez en Swing ou GWT, vous pourrez modifier l'interface utilisateur de la même manière - remplacer les classes d'interface utilisateur nécessaires, les changer, injecter les versions modifiées. Avec JSP - il y aura probablement beaucoup de modifications aux fichiers .jsp dans votre version personnalisée.

Pour ce qui est de la modification et de la correction des bogues, on utilise pleinement le système de contrôle de version. Bien sûr, vos versions spécifiques au client sont des branches, tandis que la version principale, standard, est le tronc. Les corrections de bogues sont apportées au tronc, puis fusionnées dans les branches spécifiques au client. Avec les implémentations d'interfaçage/overriding, la plupart des fusions se font de manière simple, cependant, avec JSP, je m'attends à ce que les conflits soient fréquents...

En général, les modifications du code fusionnent plus facilement que tout ce qui est basé sur XML.

2voto

Jonathon Reinhart Points 40535

Que diriez-vous d'un simple OOP ? Définir une interface/classe de base réaliste et, en fonction d'une configuration quelconque, instancier la classe enfant A ou B, selon le client. Il est difficile de fournir plus de détails pour une question aussi indépendante du langage, mais je pense que c'est très réaliste.

2voto

Adam Mihalcin Points 8816

Une solution à ce problème, courante dans le monde Win32/.NET, consiste à déplacer le "code" spécifique au client dans des fichiers de ressources. De nombreux projets .NET (.NET dispose d'un support intégré pour ce modèle par le biais de la fonction Ressources du système ) utilisent ce modèle pour l'internationalisation, en plaçant les chaînes de l'interface utilisateur dans un fichier par langue, puis en chargeant les chaînes de l'interface utilisateur à partir du fichier approprié au moment de l'exécution.

Comment ce modèle s'applique-t-il à une application JSP ? Dans ce cas, vous pouvez conserver un fichier de ressources par client (ou, au lieu de fichiers, utiliser une base de données), et charger les personnalisations spécifiques à l'utilisateur à partir du fichier de ressources chaque fois que vous servez une page.

Disons par exemple que votre plus gros client souhaite que son logo soit superposé à une partie de chaque page web de votre site. Votre page pourrait charger le CustomerLogo et l'utiliser comme attribut src de l'image HTML à cet endroit de la page. Si vous servez la page au client important, vous chargez l'URL "/static/images/importantCustomerLogo.png", et sinon vous revenez au fichier de ressources par défaut, qui spécifie l'URL "/static/images/logo.png".

De cette façon, vous pouvez extraire le code de chargement des propriétés dans un ou deux fichiers Java et utiliser ces propriétés dans tout le site Web. La seule partie de votre base de code qui est spécifique au client sera l'ensemble des fichiers de ressources, et ceux-ci peuvent être dans un format XML propre qui est facile à lire et à modifier. Le résultat est que les personnes qui n'ont pas développé l'application au départ peuvent modifier le XML sans avoir à lire le code au préalable, de sorte que vous n'aurez pas à maintenir les fichiers de ressources - le service commercial peut faire ce travail pour vous.

1voto

Nitzan Volman Points 1599

GWT le fait d'emblée via une fonctionnalité appelée liaison différée

Lors de la compilation d'une application GWT, le compilateur génère en fait différentes versions du code ciblé pour chaque navigateur différent. Ceci est fait automatiquement avec les composants GWT qui prennent soin des détails sanglants des différents navigateurs.

Cette fonctionnalité peut être étendue pour produire des compilations arbitraires basées sur des propriétés personnalisées. Voici un exemple simplifié : supposons que vous ayez des définitions de vue différentes pour une vue normale et une vue détaillée.

public abstract class AbstractView { ....}
public abstract class NormalView extends AbstractView { ... }
public abstract class DetailedView extends AbstractView { ....}

vous pouvez créer une définition de module qui générera deux versions différentes, l'une utilisant l'option NormalView l'autre en utilisant la DetailedView (dans votre fichier gwt.xml)

<define-property name="customMode" values="normal,detailed" />

<replace-with class="com.example.NormalView">
  <when-type-is class="com.example.AbstractView" />
  <when-property-is name="customMode" value="normal" />
</replace-with>

<replace-with class="com.example.DetailedView">
  <when-type-is class="com.example.AbstractView" />
  <when-property-is name="customMode" value="detailed" />
</replace-with>

en utilisant

AbstractView view = GWT.create(AbstractView.class);

fournira l'instance appropriée au moment de l'exécution.

C'est à vous d'encapsuler votre code spécifique au client dans des classes spécifiques, et d'exposer des interfaces communes pour les différentes implémentations.

Vous devrez également sélectionner la version compilée appropriée en fonction du client en cours de visualisation (vous pouvez utiliser jsp pour cela).


veuillez ne pas considérer les exemples de code ci-dessus comme testés, il peut y avoir des problèmes de syntaxe, ils sont juste destinés à transmettre l'idée générale.


Un backend JSP est un environnement d'hébergement idéal pour une application GWT, vous pourrez profiter du mécanisme requestfactory pour une communication facile entre le client et le serveur.

Il est évident qu'il y a une courbe d'apprentissage ici, mais l'IMO documentation officielle est un bon point de départ.

0voto

romje Points 609

Je pense que vous devriez essayer de lire des articles (ou des livres) sur l'OSGi... Cette plate-forme vous apporterait une réponse très pragmatique à vos problèmes de modularité. Elle est spécialement conçue pour pouvoir gérer différents modules vivant tous ensemble avec des dépendances et des versions. Comme mentionné au début d'une réponse, l'injection de dépendances à travers les services déclaratifs OSGi est une alternative très valable à Spring, avec des capacités dynamiques... Déployer un bundle fournissant un service et vos références seront mises à jour automatiquement, le laisser tomber et elles seront également rafraîchies... Jetez un coup d'œil à cette technologie et posez vos questions après ? Salutations jerome

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X