Discussion :

[Bertrand_g]

Bonjour,

Pour le développement d'une application en c++ mono-poste, j'ai décidé de m'appuyer sur une architecture en 4 couches inspirée de ce schéma : http://img97.imageshack.us/img97/3013/couchests9.png

J'ai plusieurs questions de mise en œuvre :

1) Est-ce que le concept de DTO existe en c++ ? Je l'ai surtout vu en Java...
Personnellement, j'ai procédé de la sorte : le contrôleur applicatif contient des objets DTO. Lorsque l'ihm demande des informations, le contrôleur applicatif remplit le DTO concerné et retourne un pointeur vers ce DTO.

2) Est-ce que le contrôleur applicatif est le seul interlocuteur avec l'ihm ? Dans mon cas, j'ai aussi implémenté le modèle de conception observateur où des éléments d'ihm observent des contrôleurs métiers. Autrement dit, il s'agit d'une entorse au schéma mentionné précédemment. Est-ce correct ou vaudrait-il mieux n'avoir qu'un seul point d'entrée pour l'ihm à savoir le contrôleur applicatif ?

3) Comment faire les liaisons entre couches ? En l'occurrence, j'utilise des pointeurs vers les objets des couches inférieures. Par exemple, les contrôleurs métiers possèdent des pointeurs vers les objets métiers qu'ils manipulent. Est-ce correct ?

Merci d'avance pour vos avis.

Benoît

[wiztricks]

Salut,

L'architecture technique 4 couches présentée me semble un peu "riche" pour une application c++ mono-poste mais vous avez certainement de bonnes raisons pour ce choix.

1) Est-ce que le concept de DTO existe en c++ ? Je l'ai surtout vu en Java...

Bah... DTO et DAO sont des concepts qui permettent de partager rôles et responsabilités entre les differents composants (ici classes) de l'application.
Un langage est un outil permettant de les réaliser mettre en œuvre +/- facilement.

Ce qui peut être important côté "concept" est que nous puissions partager les abstractions correspondantes. Dans votre exemple d'architecture, j'ai des difficultés à comprendre comment/pourquoi ont été placés DTO et DAO là ou ils sont (par rapport aux définitions données par les URLs)

La vraie question est de savoir si cette architecture est de votre cru ou est-elle documentée par ailleurs? car je peine à comprendre l'intérêt de l'arité des associations entre les entités de chaque couche.
Note: Si c'est une architecture générique, elle mérite peut être une description différente.

2)Est-ce que le contrôleur applicatif est le seul interlocuteur avec l'ihm?

Votre schéma laisse penser que l'IHM est sous le contrôle de deux applications. C'est pas interdit mais çà complexifie un peu ce que recouvre IHM dans ce cas. Sinon, si vous vous appliquez à suivre un modèle MVC, les "interlocuteurs"/composants liées à l'IHM sont View et Controller.

3) Comment faire les liaisons entre couches ?

Ah ben oui, décomposer c'est bien mais on se retrouve avec des bouts à intégrer dont le nombre n'a parfois qu'une valeur ajoutée 'non fonctionnelle'.

En l'occurrence, j'utilise des pointeurs vers les objets des couches inférieures. Par exemple, les contrôleurs métiers possèdent des pointeurs vers les objets métiers qu'ils manipulent.

A l'intérieur de la couche métier, contrôleurs et objets peuvent avoir des mécaniques de liaison spécifiques.

La communication entre couche relève d'une problématique différente car vous pouvez souhaiter une certaine opacité entre objets/fonctions présentées par l'API de la couche métier et la réalisation de celle ci.

Avec de simple pointeurs, il sera difficile d'assurer que les clients (de la couche) n'utiliseront que les méthodes de l'API: çà fonctionne, mais si la maintenabilité est un des objectifs de la séparation "en couche", il sera plus couteux à atteindre.

Cordialement,
- W

[Bertrand_g]

Bonjour,

Merci déjà pour votre réponse.

L'architecture technique 4 couches présentée me semble un peu "riche" pour une application c++ mono-poste mais vous avez certainement de bonnes raisons pour ce choix.

Mon idée première était de réaliser une application bien structurée pour la maintenance.
Nous avons fait un choix d'ihm (utilisation de wxWidgets) mais je voulais me laisser la possibilité de changer éventuellement. De même, le système de stockage va évoluer (des fichiers aujourd'hui pour une version alpha) avec l'utilisation d'un véritable SGBD.
Quant à l'aspect "trop riche", je suis en train de l'expérimenter à mes dépens : objet qui appelle un autre, qui appelle, etc. Que préconisez-vous comme architecture plus simple ?

cette architecture est de votre cru ou est-elle documentée par ailleurs

Cette architecture n'est pas de mon cru. Le schéma provient d'un autre post mais je ne parviens pas à le retrouver pour le moment.

Votre schéma laisse penser que l'IHM est sous le contrôle de deux applications

J'avoue ne pas bien comprendre votre remarque.

Avec de simple pointeurs, il sera difficile d'assurer que les clients (de la couche) n'utiliseront que les méthodes de l'API: çà fonctionne, mais si la maintenabilité est un des objectifs de la séparation "en couche", il sera plus couteux à atteindre.

Quelle méthode serait plus adaptée ?

Plus généralement, je suis preneur de conseils ou d'informations (d'autres discussions plus adaptées à mon type d'application par exemple). J'ai cherché mais je suis noyé sous les différentes informations. Souvent, je ne vois pas bien la traduction concrète des concepts évoqués dans les discussions.

Merci d'avance pour votre aide.

Benoît

[wiztricks]

Salut,

Quant à l'aspect "trop riche", je suis en train de l'expérimenter à mes dépens : objet qui appelle un autre, qui appelle, etc. ?

Ah ben...
Ce qui m'a fait réagir est que vous l'associez à une "application c++ mono-poste". En relisant votre réponse, je m'aperçois aussi que vous mettez l'emphase sur la maintenabilité, l'évolutivité,..

Simplifiez!

Si nous nous appliquons à décomposer, c'est pour répartir/organiser le travail. Maintenant découper une fonctionnalité en 3 ou en 10 morceaux ne changera pas les résultats - n'apportera rien au métiers - juste les 'overheads' de gestion d'un nombre de morceaux plus important côté:

• documentation,
• interfaces,
• réalisations,
• tests

Et comme le puzzle aura plus de pièces, il sera beaucoup plus délicat à maintenir et à faire évoluer.

Que préconisez-vous comme architecture plus simple ?

La complexité de l'architecture technique doit être 'proportionnée' avec sa complexité fonctionnelle. Comme j'ignore tout de celle-ci, je ne peux donner d'avis, juste espérer que vous avez bien fait votre boulot...

Ces préoccupations, lorsqu'on fait du développement de produit diffusé à des millions d'exemplaire (ou l'exemplaire unique qui aille sur Mars), n'ont pas les mêmes implications côté structure/qualité qu'une application utilisée par quelques employés d'un service administratif.

- W
PS: J'ai eu la chance de travailler sur ces trois types de projets, je sais par expérience que même le mot 'simple' n'a pas le même sens partout.

[Bertrand_g]

Simplifiez!

Ok, j'ai compris le message.
Je vais déjà éjecter les notions de DTO et de contrôleur d'application.

une application utilisée par quelques employés d'un service administratif

On se situe plutôt dans ce cas de figure, ce qui confirme la devise précédente.

Merci pour ces conseils.

Benoît

[wiztricks]

Bonjour

Citation:
une application utilisée par quelques employés d'un service administratif

On se situe plutôt dans ce cas de figure, ce qui confirme la devise précédente.

Ne simplifiez pas trop non plus.
Quels sont les attributs de l'architecture technique que vous présentiez initialement qui vous l'ont fait préférer à un modèle plus classique
MVC/2Tiers ?

Lisez un peu le post, il présente des questions similaires.
- W

[Bertrand_g]

Bonjour,

Quels sont les attributs de l'architecture technique que vous présentiez initialement qui vous l'ont fait préférer à un modèle plus classique
MVC/2Tiers ?

Je précise quand même : je n'ai pas beaucoup d'expérience par rapport aux différentes architectures.

Pour moi, je comprenais l'architecture en 4 couches proposée par rapport à l'architecture MVC de la façon suivante :
- vue = ihm ;
- contrôleur = contrôleur applicatif + contrôleurs métiers ;
- modèle = objets métiers + couche d'accès aux données
Cependant, ma compréhension est peut-être erronée...

Dans le cas présent, je veux être capable de changer facilement de stockage de données (fichier -> véritable SGBD), d'où la scission entre objets métiers et objets d'accès aux données. J'ai implémenté le pattern DAO. Sur cette partie, j'étais plutôt satisfait.

En conséquence, en séparant objets métiers et couche DAO, je me rapprochais à mon sens de l'architecture 4 couches proposée. Après, je me trompe peut-être...

Je vais regarder l'autre post.

Benoît

[wiztricks]

Pour moi, je comprenais l'architecture en 4 couches proposée par rapport à l'architecture MVC de la façon suivante :
- vue = ihm ;
- contrôleur = contrôleur applicatif + contrôleurs métiers ;
- modèle = objets métiers + couche d'accès aux données
Cependant, ma compréhension est peut-être erronée...

Au début, le cahier des charges permet de définir les différentes fonctionnalités 'métier' à réaliser.
S'il s'agit d'une application interactive, MVC propose une architecture technique qui permet de placer, répartir assez facilement et logiquement différentes opérations effectuées par les fonctionnalités métiers à réaliser.
MVC est une architecture de "premier" niveau: au fur et à mesure que la connaissance sur le domaine se précise, il faudra découper chaque niveau et parfois remettre en cause la distribution des rôles, voire le découpage 'en partie'.

Le vrai problème de l'architecture MVC qui n'est pas sans impact sur la maintenabilité et le coût des évolutions est dans la définition du "Modèle".

Soit on se contente d'y mettre la couche d'accès au données soit on y met aussi les entités 'métiers' avec l'ensemble des opérations qu'on peut y faire dessus. On peut faire gonfler le modèle jusqu'à être une couche de services métiers avec un cycle de vie indépendant et pouvant supporter différents types de clients applicatifs - appelons cela le coeur - .
Dans ce cas, vous avez une architecture en 4 parties: Les trois composants du MVC d'une des applications et le "coeur". Dans ce cas, le Model intégre une interface avec le coeur et une fonction de persistance 'spécifique' à l'application.

Dans le cas présent, je veux être capable de changer facilement de stockage de données (fichier -> véritable SGBD), d'où la scission entre objets métiers et objets d'accès aux données. J'ai implémenté le pattern DAO. Sur cette partie, j'étais plutôt satisfait.

Le Model est une couche avec au dessus les services qu'il présente aux View et aux contrôleurs et au dessous les fichiers ou la BDD.

Comme vous faites de la POO, le mapping entre les "objets" et leurs données "persistées" pourra se faire "à la main" ou en utilisant un ORM i.e. un outil qui fait déjà cela en partie.

En conséquence, en séparant objets métiers et couche DAO, je me rapprochais à mon sens de l'architecture 4 couches proposée. Après, je me trompe peut-être...

Pour l'instant, c'est quelque chose qui se passe de toute façon 'à l'intérieur' du Model. Autrement dit, partir d'un découpage de premier niveau en 3 morceaux n'interdit par un découpage plus fin de chaque morceau dans des niveaux de décomposition inférieurs.

Mais rien n'interdit de montrer en premier niveau un découpage en 4 blocs: tout dépend de l'emphase que vous voulez mettre pour montrer comment sont effectivement réalisées l'ensemble des fonctionnalités demandées. Ou de la volonté d'avoir plusieurs applications s'appuyant sur un coeur de fonctionnalités métiers - dans ce cas, le coeur devient la 4ème composante de l'architecture.

C'est la raison pour laquelle je me suis permis d'insister sur le pourquoi de votre choix initial: en montrant cela vous traduisiez certaines préoccupations.
- W

[Bertrand_g]

Au début, le cahier des charges permet de définir les différentes fonctionnalités 'métier' à réaliser.

Autrement dit, les cas d'utilisation ?

Soit on se contente d'y mettre la couche d'accès au données

Avec l'inconvénient d'un contrôleur assez lourd ?

soit on y met aussi les entités 'métiers'

A priori, j'étais plutôt dans cet esprit.

le mapping entre les "objets" et leurs données "persistées" pourra se faire "à la main"

Je pensais procéder ainsi à moins qu'il existe des outils simples à appréhender en c++...

Petite question/confirmation par rapport à MVC :
Si la vue demande une modification "en écriture", elle va le faire auprès du contrôleur.
Si elle souhaite accéder aux objets métiers en lecture, elle peut le faire directement.
C'est bien ça ?

Pour en revenir à la nécessité de simplification, je pense :
- supprimer les DTO ; ils me paraissent ajouter une complexité inutile pour l'instant ; la vue contiendra des pointeurs vers les objets métiers pour connaître leur état ;
- supprimer sans doute les contrôleurs métiers ; l'application est suffisamment simple pour que le contrôleur d'application gère tout. A voir par la suite.

Merci pour votre regard.

Benoît

[wiztricks]

Petite question/confirmation par rapport à MVC :
Si la vue demande une modification "en écriture", elle va le faire auprès du contrôleur.
Si elle souhaite accéder aux objets métiers en lecture, elle peut le faire directement.
C'est bien ça ?

Oui.
Mais WxWidgets sera beaucoup plus structurant car il propose un modèle doc/view quelque peu différent.

En fait, dans la démarche de conception il y a une approche de planification qui se traduit par une démarche 'top-down' dans laquelle on reformule les exigences métiers et une approche de construction qui retraduit tout cela en fonction des outils/frameworks retenus.

La difficulté est d'arriver à faire converger les deux

Si l'application n'est pas trop compliquée et qu'on maîtrise assez bien les possibilités de l'outil, on peut dans certains cas "construire" directement.
Dans ce cas, la convergence est assurée, au prix de quelques ennuis côté traçabilité des exigences et éventuellement pour le remplacement du framework ou la maîtrise des coûts des évolutions.
Note: ce n'est pas recommandable mais rien n'interdit de...

Pour en revenir à la nécessité de simplification, je pense :
- supprimer les DTO ; ils me paraissent ajouter une complexité inutile pour l'instant ; la vue contiendra des pointeurs vers les objets métiers pour connaître leur état ;
- supprimer sans doute les contrôleurs métiers ; l'application est suffisamment simple pour que le contrôleur d'application gère tout. A voir par la suite.

Je suis plutôt pour l'école FAT Model: tous les changements des objets métiers devraient se faire via des méthodes associées à l'intérieur ou dans le Modèle. i.e. différentier la logique métier de la logique applicative.
Mais c'est vous qui tenez le couteau.
- W

[Bertrand_g]

Bonjour,

Mais WxWidgets sera beaucoup plus structurant car il propose un modèle doc/view quelque peu différent.

J'ai vu effectivement mais j'avoue craindre de perdre du temps à assimiler ce modèle. Par ailleurs, j'ai peur de l'aspect "carcan" (peut-être à tort).
Pour l'instant, je n'envisage pas de l'utiliser.

Je suis plutôt pour l'école FAT Model: tous les changements des objets métiers devraient se faire via des méthodes associées à l'intérieur ou dans le Modèle. i.e. différentier la logique métier de la logique applicative.

Ok, je vois.
En fait, si on prend l'exemple fictif de l'ouverture d'un document, je pensais procéder comme suit :
1) la vue demande au contrôleur d'application d'ouvrir un document ;
2) celui-ci met à jour ses variables membres (par exemple, un booléen indiquant qu'un doc est ouvert) puis appelle la méthode d'ouverture de l'objet métier correspondant ;
3) L'objet métier avertit la vue qu'elle doit se mettre à jour.
Le rôle du contrôleur applicatif est donc assez limité à celui d'une tour "de contrôle".

Benoît

[wiztricks]

Hmmm
Je n'ai pas trop le temps de vous répondre longuement, mais j'ai trouvé ce post de pseudocode qui résume pas mal les choses.
Note: la différence étant que je "cache" la structure du 2nd MVC dans le modèle du premier, celui ci n'ayant pas vraiment à savoir ce qui se passe en dessous.
- W