Personnalisations du client

Question

Nous avons un produit avec une base d'installation d'environ 50 personnes. Plus de 50% de ces installations ont des personnalisations dans le code de la logique métier, et cela est actuellement effectué par d'énormes instructions IF et Switch.

Nous sommes actuellement en train de mettre à jour le code vers .NET 3.5 et nous aimerions gérer les personnalisations de manière plus gérable. Pour le moment, les seules solutions envisageables sont de s'en tenir aux grandes instructions IF et Switch, ou de placer des fichiers distincts dans le contrôle de code source pour chaque client, ce qui, encore une fois, ne semble pas être idéal.

Existe-t-il un moyen accepté de gérer un grand nombre de personnalisations sur une base de code?

Answer 1

Je serais tenté d'organiser les choses de manière à ce que la personnalisation soit sous forme de texte (éventuellement XML, mais je suppose que ce n'est pas la seule option), et l'application principale est générique et obtient les fonctionnalités spécifiques du client en analysant ces fichiers de configuration. .

Vous pouvez ensuite avoir un référentiel pour chaque client, contenant des fichiers de configuration (et éventuellement des ressources, telles que des logos et / ou des scripts personnalisés), ainsi qu'un référentiel pour l'application principale.

Pour une version client donnée, votre système de génération rassemble automatiquement l'application et le référentiel du client, puis crée la version personnalisée.

J'ai de l'expérience avec un tel système et vous pouvez obtenir une personnalisation assez poussée de cette façon. Cela complique les choses du côté de l'application au début, car vous devez ajouter une fonctionnalité d'analyse syntaxique, mais cela simplifie considérablement la gestion des différentes versions du client, tout en réduisant le risque d'erreur.

Answer 2

N’est-ce pas appelé l'héritage ? Avoir des classes étendues à partir de classes de base en ajoutant des fonctionnalités personnalisées. Chaque fois que j'ai un grand nombre de if ou de cas, je me demande si je devrais refactoriser plusieurs classes.

Answer 3

Un framework DI associé à un héritage peut maintenir votre système conformément au principe Open / Closed, le rendre plus modulaire et résoudre les problèmes de cycle de vie et de distribution, comme lorsque vous devez distribuer une bibliothèque de base étendue pour une période donnée. client spécifique.

Par exemple, vous pouvez avoir une classe Transfer dans BaseLibrary, puis une classe LoggingTransfer extended Transfer dans la bibliothèque CustomerX contenant uniquement le code qui personnalise les fonctionnalités de base.