Discussion :

[Kelpan]

Bonjour,

Je me questionne sur la gestion des spécifiques dans une application.

Dans mon cas, nous sommes en pleine réécriture du logiciel en .NET, et j'aimerais en profiter pour remmettre en question la gestion des spécifiques qui se limitait à tester le numéro de série client dans les sources.
Personnellement, je trouve cela ... horrible ...., ce n'est pas l'avis de tous mes collègues. Je veux bien me remettre en cause, mais je veux être convaincu qu'on pas faire mieux que ça pour gérer les spécifiques.

Personnellement, moi j'étais partant pour faire une dll qui contiendrait tous les programmes spécifiques des clients.
Pour les spécificités sur les modules standards, on pourrait utiliser l'héritage de classe ...
Mais bon, ce système, impose ses inconvenients aussi... Il faudrait compiler une application par client avec sa dll... je pense pas qu'il vont opter pour une solution comme celle-ci.

Et vous ? Comment voyez-vous la gestion des spécifiques ?

Certains ont peut être trouver une recette miracle.
Ils peuvent peut être faire partager leur expérience.

[Kelpan]

Aucun avis ?

[SaumonAgile]

Bonjour,

Je me questionne sur la gestion des spécifiques dans une application.

Dans mon cas, nous sommes en pleine réécriture du logiciel en .NET, et j'aimerais en profiter pour remmettre en question la gestion des spécifiques qui se limitait à tester le numéro de série client dans les sources.
Personnellement, je trouve cela ... horrible ...., ce n'est pas l'avis de tous mes collègues. Je veux bien me remettre en cause, mais je veux être convaincu qu'on pas faire mieux que ça pour gérer les spécifiques.

Personnellement, moi j'étais partant pour faire une dll qui contiendrait tous les programmes spécifiques des clients.
Pour les spécificités sur les modules standards, on pourrait utiliser l'héritage de classe ...
Mais bon, ce système, impose ses inconvenients aussi... Il faudrait compiler une application par client avec sa dll... je pense pas qu'il vont opter pour une solution comme celle-ci.

Et vous ? Comment voyez-vous la gestion des spécifiques ?

Certains ont peut être trouver une recette miracle.
Ils peuvent peut être faire partager leur expérience.

Tu peux créer des modules spécifiques pour chaque client en utilisant un système de chargement de modules dynamique. Avec du code bien écrit, tu dois pouvoir t'en sortir sans modifier le module principal. Ensuite, il suffit juste de mettre la bonne assembly pour le client et peut-être pour simplifier une ligne de configuration dans le système (app.config, DB, etc).

[Kelpan]

Si j'ai bien compris, il faut créer les modules spécifiques dans une ou des assemblies qui ne sont pas compilés dans la version standard.

Ensuite, il suffit de charger le ou les asemblies qui contiennent les spécifique dynamiquement selon un ou des paramètres.

Ce système permet d'eviter une compilation par client. C'est un bon point.
Par contre, je ne suis pas sur que cela puisse résoudre tous les cas de spécificité.

J'identifie pour le moment 2 cas de spécificité :
1. Un traitement ou un module qui n'appartient pas au standard
2. Une modification d'un traitement du standard

Pour le premier cas, un module à part est développé (il n'existe pas)

Pour le deuxieme cas, un module étant existant, faut-il dupliquer le module en y ajoutant les spécificités pour chaque client ou faire des tests de spécificité à l'intérieur du module standard (test du numéro de série par exemple !) ?

[cinemania]

le problème c'est qu'il n'y a encore une fois pas de vraie réponse à ta question.

Tout est question de choix et de préférences.
Moi personnellement je suis pour l'ultramodulaire. Autrement dit... tout ce qui concerne un spécifique client (et les comportements non standards associés) doit faire parti d'un module client. A toi de faire un noyau dynamique qui gère tous les cas que tu rencontrera.

C'est ma façon de voir les choses, mais il y en a d'autres. Moi je viens d'un univers où la modularité est souveraine, mais d'autres ne le voient pas de cet oeil.

C'est à toi de te forger ta propre opinion, qui va devoir aussi dépendre des compétences dont tu dispose, ou dont tes collegues disposent.
Car au dela de l'aspet programmation, il faut aussi l'imagination et les idées pour développer des architectures.
Il serait préjudiciable, à mon sens, que vous (car je suppose que tu n'est pas seul) vous lanciez dans le développement d'une solution ultramodulaire ultracomplexe à mettre en place, si aucun d'entre vous n'a les compétences, et l'expérience dans le domaine.
C'est un coup a prendre des retards monstres, et se faire foutre à la porte.
(et ca c'est dans le cas où ca marcherait... ce qui n'est pas certains)

Si en revanche, un d'entres vous à les compétences, où est suffisamment "fou" il peut toujours s'y coller.
Quoi qu'il en soit, faites des diagrammes, et pas mal de scénarii pour arriver à en déduire une architecture viable.

Enfin si vous vous aventurez sur cette voie... il existe des namespaces incontournables :
- System.Reflection
- System.Reflection.Emit
- System.Security
- System.Globalization

les 3 premiers sont les plus importants, surtout le tout premier. Il est à la base meme de toute liaison tardive et chargement dynamique.
le second si tu as besoin d'injection dynamique de code (et dans un noyau dynamique c'est parfois un mal nécessaire)
le troisième pour règler certains attributs de sécurité pour ton code pour qu'il soit autorisé à faire certaines choses au niveau de la reflexion.
le quatrième est parfois nécessaire lors de la reflexion, surtout si dans les spécifiques clients tu gere les différentes cultures.

[Kelpan]

le problème c'est qu'il n'y a encore une fois pas de vraie réponse à ta question.

Tout est question de choix et de préférences.

Oui, quand tu fais des recherches sur la gestion des spécificités sur le net, tu ne trouve rien.
Sinon, au niveau des choix et des préférences, je n'en vois pas tellement.

Sinon, J'ai vu que dans la version .net 2005, il y a une nouvelle notion 'Partial Class'. Est-ce un pas un pas vers la gestion des spécificités ?

[trolldom]

il y a une nouvelle notion 'Partial Class'. Est-ce un pas un pas vers la gestion des spécificités ?

Une classe partielle est juste une sépraration fysique du code d'une même classe. C'est bien pratique en combinaison avec des générateurs de codes qui peuvent régénérer le code d'une classe sans écraser le code du développeur qui est écrit dans un autre fichier (en utilisant le mécanisme des classes partielles). msdn

It is possible to split the definition of a class or a struct, or an interface over two or more source files. Each source file contains a section of the class definition, and all parts are combined when the application is compiled. There are several situations when splitting a class definition is desirable:

When working on large projects, spreading a class over separate files allows multiple programmers to work on it simultaneously.

When working with automatically generated source, code can be added to the class without having to recreate the source file. Visual Studio uses this approach when creating Windows Forms, Web Service wrapper code, and so on. You can create code that uses these classes without having to edit the file created by Visual Studio.

Nous avons le même type de problème de version de client. Nous allons essayé de passé à des applications modulaire mais c'est souvent des architectures abstraites et plus compliquées. Comme premier pas je prends l'habitude d'essayer de résoudre les branchements conditionnels par le design par example avec des stratégies pour le choix d'algorithmes de calculs en fonction du client.
J'avais commencé à regarder l bloc applicatif de Microsoft CAB (Composite UI aplication block?) pour la gestion modulaire des UI mais je n'ai pas eu le temps de m'y mettre sérieusement.
Dom