Discussion :

[mactwist69]

Bonjour à tous,

Je souhaiterai me lancer dans le développement d’une application qui suivant les cas, pourrait contenir différents modules.

Donc pour partir dans la bonne direction, j'ai commencé par lire ce qui se fait question architecture et j'en ai lu pas mal ces derniers temps, malheureusement il y a beaucoup d'information voir parfois de confusions donc je m'excuse d'avance si je me trompe ou si ce n'est pas clair.

Dans le souci de faire un développement stable, actualisable et adaptable, il semble qu'une architecture 4 couches semble intéressante (Par couches j'entends: IHM, BPL, DAL et DEL):

- Possibilité d'avoir une IHM lourde ou légère
- Couche métier clair et stable
- Possibilité d'avoir plusieurs type de sources de données (SQL server, Mysql)
- Type de données transverse
La communication se ferait par librairies... donc via des dlls (si j’ai bien compris)
Déjà, est ce que ca vous semble correct jusque là ?

Par contre pour le côté « organisation » de la solution, j’ai plusieurs doutes.
Dans un premier temps il s’agirait d’un logiciel de type client lourd, Winform… (Bien que ce ne soit pas à la mode). En étudiant certains exemples, j’ai vu des exemples avec un IHM, avec les 3 dll correspondantes…

Certaines versions pouvant avoir des modules totalement différents de certaines autres, il me semble que ces modules devraient avoir une couche métier (et donc des DEL et des DAL ?) dans des fichiers différents ? Et suivant le cas, la solution fera référence aux dll qui lui convient ? L’interface, elle devant bien sûr pouvoir s’adapter ou être spécifique…

Ou est ce que quand j’entends parler de réutilisation de certains éléments "métier" de ces couches, on entend « copier/coller » de bouts de code, d’un projet à un autre ? Car je ne vois pas l’intérêt de faire une méga solution, qui ne serait utilisé qu’à 10% dans certains cas… Ou est ce que j’ai rien compris ?

[pseudocode]

Ou est ce que quand j’entends parler de réutilisation de certains éléments "métier" de ces couches, on entend « copier/coller » de bouts de code, d’un projet à un autre ? Car je ne vois pas l’intérêt de faire une méga solution, qui ne serait utilisé qu’à 10% dans certains cas… Ou est ce que j’ai rien compris ?

Il y a deux notions derrière le mot "modularité".

La modularité "technique" consiste a pouvoir décomposer et isoler les mécanismes (au sens "plomberie" logicielle). C'est ce qu'on observe traditionnellement dans les architectures en layers, où chaque niveau à une responsabilité technique.

La solution technique mise en oeuvre dans chaque layer peut alors être réutilisée dans une autre application. Cette réutilisation est d'autant plus facile que la solution technique est généralement configurable. Exemple le niveau BEL/DEL qui est constitué d'un ensemble SGBD (solution générique) + schéma (configuration spécifique).

La modularité "fonctionnelle" consiste a pouvoir décomposer et isoler les fonctions (au sens "service rendu" à l'utilisateur) de l'application. C'est typiquement ce qu'on observe dans les applications core+plugin (par exemple "eclipse") ou les applications multi-agents.

Si l'on représente les layers techniques en "horizontales", la modularité fonctionnelle serait en "verticales".

[mactwist69]

Merci bien pseudocode, je comprends maintenant la distinction entre ces deux modularités.

Je pensai effectivement a un mode qui n'existe pas, en me basant sur la modularité mode layer tout en voulant la transformer en fonctionnel...

Donc si je comprends bien, en me basant sur ce que je veux faire, j'ai deux solutions:

- Soit faire une application comprenant tout les modules qui ne seront activé que dans certain cas.
Avantages: Facilité de mise à jour / activation de nouveaux modules (si non spécifique)
Inconvénient: Toutes les solutions seront "lourdes" si j'ose dire avec la plupart du temps un tas d'information inutile, donc éventuellement moins lisible...

- Soit avoir un gros Template/librairie comprenant tout les modules, dont je vais puiser des informations
Avantages: Chaque solution est spécifique et ne contient que ce qu'il faut / réutilisation du travail existant
Inconvénients: Si une version veux intégrer un nouveau module, il faut re modifier le code, compiler etc...

D'après votre expérience qu'en pensez vous ?

[Edit1: Vous allez me dire, ça dépends du nombre de modules fonctionnels de l'application: en fait il est censé y avoir une dizaine de modules génériques, utilisable par tous, et un certains nombre de modules fonctionnels "métier" qui eux se feront au compte goutte...

Donc j'en viens à me demander si il ne faut pas que je fasse un mix entre mes deux propositions: Une application template contenant les modules génériques (genre librairie), avec en parrallèle des versions métiers

D'un point de vue programmation, les modules génériques seront mis à jour dans le template et reportés dans les templates "métier".
D'un point de vue mise à jour client, toutes les solutions du même métier pourront être mis à jour d'un coup en cas de mise à jour métier, par contre pour le cas d'une mise à jour d'un module générique, toutes les versions métier devront être mis à jour, recompilé, déployé...Mais sachant que les modules génériques devront être stable, dans la théorie cela devrait moins arrivé]

(Une petite question annexe sur la plomberie, la Business Layer, sera en fait uniquement composé de classes de "gestion", utilisant des objet de l'Entité layer et de la dal ?)

[pseudocode]

Donc j'en viens à me demander si il ne faut pas que je fasse un mix entre mes deux propositions: Une application template contenant les modules génériques (genre librairie), avec en parrallèle des versions métiers

C'est exactement ce que Eclipse a choisi de faire avec son architecture "RCP" (Rich Client Platform).

(Une petite question annexe sur la plomberie, la Business Layer, sera en fait uniquement composé de classes de "gestion", utilisant des objet de l'Entité layer et de la dal ?)

Business Layer = Business Process Layer + Business Entity Layer

La BPL gère les activités, les workflow et d'une manière générale le "comportement métier" de l'application.
La BEL gère les entités métiers, c'est à dire les données manipulées par les activités de la BPL.

[mactwist69]

Super, merci pour ces informations précieuses !
Sur la théorie j'ai plus de souci !

Par contre il me reste une question technique car j'ai juste un doute concernant la séparation IHM / BPL.

Car jusque là je travaillais en mono-couche si j'ose dire... Et en organisant mes logicielles j'étais naturellement arrivé à séparer l'interface des classes de gestion, des classes d'entité...

Mais quelques fois, dans l'interface, quand celle-ci est complexe, on a besoin de faire appel aux classes de gestion (dans le futur cas de la BPL), mais également d'l'interpréter le résulat métier pour faire des changements dans l'IHM.

Or si j'ai bien compris, dans le découpage en couche, il faudrait en théorie réduire au maximum le code d'interpretation de l'IHM, cela ceut il dire que L'IHM n'a pas de classe d'auto-gestion ?

Donc quelque part, est ce qu'il faudrait que la BPL contienne une classe métier pour l'IHM qui va interpréter les données métier et la transcrire de manière simple pour les besoins de l'IHM ?

Ou est ce que dans ce mode de découpage, ça reste dans les bonnes pratiques d'avoir des classes pour gérer le visuel (qui fera appel à la couche de gestion) on donc, quelque part, faire des traitements ?

(J'éspère que c'est clair... )

[pseudocode]

Mais quelques fois, dans l'interface, quand celle-ci est complexe, on a besoin de faire appel aux classes de gestion (dans le futur cas de la BPL), mais également d'l'interpréter le résulat métier pour faire des changements dans l'IHM.

Or si j'ai bien compris, dans le découpage en couche, il faudrait en théorie réduire au maximum le code d'interpretation de l'IHM, cela ceut il dire que L'IHM n'a pas de classe d'auto-gestion ?

Donc quelque part, est ce qu'il faudrait que la BPL contienne une classe métier pour l'IHM qui va interpréter les données métier et la transcrire de manière simple pour les besoins de l'IHM ?

Pour cela, on crée généralement un objet "vue" (view). C'est un objet qui contient des données provenant des Business Entity (BE), mais destinées à être manipulées par l'IHM.

La conception la plus courante pour l'IHM est le Modèle/Vue/Contrôleur, et ses variantes.

Le modèle contient les BE, la vue contient une représentation du modèle (destinée à l'affichage), et le contrôleur permet d'agir sur le modèle (ou la vue).

Exemple classique:
- les données métiers sont stockées dans une base de données.
- Le modèle contient une liste de BE construite à partir d'une requête SQL (Select ... where ...)
- La vue contient une représentation du modèle (par ex. un tableau ligne/colonne)
- Le contrôleur permet d'agir sur le modèle (par ex. suppression des objets sélectionnés) ou sur la vue (modification d'un critère de tri/filtre)

[mactwist69]

Merci pour toutes ces infos !

J'ai maintenant de quoi orienter mes petites recherches et me mettre au boulo !

EDIT 1:

Juste pour être sûr de comprendre le système MVC (appliqué à mon cas):

- Le modèle sera un enesemble d'objet dans la BE
- La vue sera l'interface à proprement parlé
- Le contrôleur sera une classe de gestion dans la BL

Est ce bien cela ?