📖 Guides · Architecture · ORM_CSHX2

Pourquoi un composant ?

ORM_CSHX2 est distribué sous forme de composant WinDev plutôt que de code source intégré directement dans le projet hôte.
Ce choix architectural est délibéré — il répond à deux impératifs fondamentaux.

English version
01

🔒 Protection des sources

Le composant représente un investissement conséquent en conception, développement et tests. Le distribuer sous forme de composant compilé (.wdk / .wdi) permet de :

  • Protéger le savoir-faire et les algorithmes internes contre la copie ou la réutilisation non autorisée.
  • Contrôler ce qui est exposé — seule l'interface publique (procédures globales ORM_* et méthodes de classe mth_*) est visible depuis le projet hôte. Les méthodes internes restent encapsulées.
  • Garantir que le code livré est celui qui a été testé — aucune modification accidentelle n'est possible sur les sources du composant.
ℹ️ Interface publique vs implémentation

Le projet hôte hérite des classes du composant ORM_CSHX2 et appelle leurs méthodes publiques. Il ne voit jamais le code interne. C'est exactement le même principe qu'une bibliothèque tierce ou un SDK commercial.

02

🔄 Maintenabilité et bénéfice des corrections

Si chaque projet intégrait le code source du composant directement, chaque équipe — ou chaque développeur — commencerait inévitablement à adapter « son » code selon ses besoins immédiats. En quelques mois :

⚠️ Le problème du code forké

Il existerait autant de versions du composant que de projets l'utilisant. Une correction de bug ou une amélioration de performance apportée sur la version de référence ne bénéficierait plus aux autres projets. La base de code se fragmente, les tests ne couvrent plus les mêmes chemins, et chaque projet accumule sa propre dette technique.

Le composant résout ce problème structurellement :

  • Une seule version de référence. Tous les projets utilisant le composant bénéficient automatiquement des corrections et améliorations lors d'une mise à jour du .wdk.
  • Pas de divergence possible. Le code du composant ne peut pas être modifié depuis le projet hôte — il ne peut qu'être étendu via héritage.
  • Montée de version contrôlée. Remplacer le fichier .wdk suffit à déployer une nouvelle version. L'interface publique étant stable, le projet hôte n'a pas à changer.
03

🏗️ Le bon modèle d'extension

Le mécanisme prévu pour adapter le composant à un projet spécifique est l'héritage, pas la modification directe.

✅ Pattern recommandé
// Dans le projet hôte — classe héritante clArticle est une Classe hérite de xFrameWork_CSHX2 // Membres métier spécifiques au projet m_sLibellé est une chaîne m_nPrixUnitaire est un réel // Les procédures ORM_* et méthodes mth_* du composant // sont disponibles directement, sans toucher une ligne du composant FIN

Toute logique spécifique au projet vit dans la classe héritante. Le composant reste intact, testable indépendamment, et remplaçable sans impact sur le projet hôte.