Discussion :

[hmimoud]

Bonsoir,

Je souhaite faire une application JAVA, et j'utilise le pattern MVC, 3 questions me sont passé par la tête :

1. Est ce que les classes qui correspondent à mon diagramme de classe et qui comporteront des attributs et des getters et setters (JavaBeans) seront dans ma couche métier(contrôleurs) ou bien à l'exterieur du pattern ?
   
2. J'ai des classes "Modèles" et des classes "Vues", et je n'ai pas vraiment des classes Contrôleurs à ajouter puisque je n'ai pas grand choses à controller à partir de mon modèle ou du moins j'essaye de controller directement dans mon modele car les les données à contrôler sont rares. Est ce que je peux m'en passer de la couche "Contrôleur" (et ne la remplir que des Java Beans, cf 1ère question) ou bien je dois impérativement la créer et commencer à y définir des methodes qui feront uniquement appel aux méthodes du "Modèle" sans aucun contrôle.
   
3. Il y a une opération qui consiste à transformer un diagramme de classe en du code, comme vous l'aurez constatez c'est le contraire de la Rétroingénieurie, et pour cela il y a des règles à respecter, et que beaucoup de logiciels permettent de faire comme "Rational Rose", etc. Parmi ces règles, il y a la liste (ArrayList en java) qu'on ajoute à une classe dans le cas d'une relation "un à plusieurs", par exemple :
   
   

   Un enseignant enseigne un ou plusieurs étudiants.

   Dans ce cas, on aura un JavaBeans enseignant avec les attributs et une liste de type étudiants et ses getters et setters, ainsi on aura une classe qui regroupera tout à la fois ce qui simplifiera le codage et la programmation.
   Ce que je voudrais simplement savoir c'est si cette opération est permise avec un JavaBeans (et pattern MVC notamment) ou pas, c'est à dire est ce que j'ai le droit de mettre cette liste dans le Bean ou bien travailler normalement avec le Bean et ses propres attributs, getters et setters, uniquement.

Merci

[Luckyluke34]

Est ce que les classes qui correspondent à mon diagramme de classe et qui comporteront des attributs et des getters et setters (JavaBeans) seront dans ma couche métier(contrôleurs) ou bien à l'exterieur du pattern ?

Attention, la couche métier ne contient pas les contrôleurs (voir plus bas). Quand aux classes métier, que tu as implémentées sous forme de beans, certains considèrent qu'elles font partie du M de MVC (donc le modèle), d'autres pensent que ce M contient des objets adaptés aux écrans et pas de purs objets métier qui sont eux hors de MVC. J'ai rencontré les deux cas.

J'ai des classes "Modèles" et des classes "Vues", et je n'ai pas vraiment des classes Contrôleurs à ajouter puisque je n'ai pas grand choses à controller à partir de mon modèle ou du moins j'essaye de controller directement dans mon modele car les les données à contrôler sont rares. Est ce que je peux m'en passer de la couche "Contrôleur" (et ne la remplir que des Java Beans, cf 1ère question) ou bien je dois impérativement la créer et commencer à y définir des methodes qui feront uniquement appel aux méthodes du "Modèle" sans aucun contrôle.

Dans MVC, la couche Contrôleurs n'est pas optionnelle. Le terme contrôleur peut être trompeur, les contrôleurs ne servent pas forcément à faire de la validation de données mais surtout à aiguiller et coordonner les appels au Modèle en fonction de l'action de l'utilisateur. Cf http://en.wikipedia.org/wiki/Model%E...0%93controller

Dans ce cas, on aura un JavaBeans enseignant avec les attributs et une liste de type étudiants et ses getters et setters, ainsi on aura une classe qui regroupera tout à la fois ce qui simplifiera le codage et la programmation.
Ce que je voudrais simplement savoir c'est si cette opération est permise avec un JavaBeans (et pattern MVC notamment) ou pas, c'est à dire est ce que j'ai le droit de mettre cette liste dans le Bean ou bien travailler normalement avec le Bean et ses propres attributs, getters et setters, uniquement.

MVC et Javabeans sont deux choses différentes. On peut faire du MVC sans Java Beans et vice versa. Les attributs d'un bean peuvent tout à fait être des listes d'autres beans. Des exemples ici : http://docstore.mik.ua/orelly/java-e...ns/ch09_07.htm

[hmimoud]

Bonsoir,

Merci Luckyluke34 pour ta réponse.

J'ai encore quelques ambiguïtés concernant le sujet. J'ai fait pas mal de recherche sur le net et notamment sur "développez", mais je ne suis toujours pas arrivé à mon but puisque à chaque fois que je trouve une réponse (qui me parait pertinente) j'en trouve une autre qui contredit la première et ainsi de suite (cela est très fréquent surtout dans les discussions des forums), cela crée un débat ce qui laisse la le problème sans réponse pertinente et du coup la discussion non résolue .

A force de chercher, j'ai même trouvé que l'architecture MVC et l'architecture 3 tiers sont parfois confondue. J'ai bien lu ces deux notions sur Wikipedia et j'ai bien déduis la différence, mais quand je veux implémenter cela réellement en JAVA, j'ai recours automatiquement à d'autres sources tels que des cours et des discussions et là je commence à me perdre dans les différentes réponses apportées. Là, j'ai essayé en quelques sortes de résumer ce que j'ai pu trouver comme réponses sur les différentes sources sur le net. Je sais bien qu'il n'existe pas d'analogie directe entre ces deux architectures différentes mais j'ai fais ça uniquement pour montrer mon problème à part entière et avoir une réponse plus claire au niveau implémentation JAVA (car au niveau théorique, j'ai bien compris l'objectif) qui décrira ce que contient vraiment le MVC et ce que contient l'architecture 3 tiers une bonne fois pour toute, pour que je puisse choisir laquelle est la meilleure pour mon application JAVA.

1- Modèle en MVC et couche DAO: il y en a qui considère que c'est, des classes qui contiennent des méthodes(ajouter, modifier, supprimer ...) définissent des instructions SQL sur la base de données (+des JavaBeans pour d'autres), alors que d'autres considèrent que c'est la base de données elle même physiquement.
2- Couche métier et contrôleur en MVC: il y en a qui disent que ce sont des JavaBeans(classes avec attributs getters et setters) et d'autres qui disent que se sont des classes qui contrôle les méthodes du DAO (controller si type numérique pour prix par exemple) tandis qu'une troisième catégories de personnes disent que cette couche contient les deux (JavaBeans + classes "control").
3- Vue en MVC et Couche IHM: Pour une fois tout le monde et d'accord que c'est la couche qui gère tout ce qui est graphique: "Swings" en JAVA.

NB: Je travaille avec JAVA SE et je souhaite appliquer une architecture (MVC ou 3 tiers)manuellement et conceptuellement sans utiliser des APIs, frameworks ..., d'une manière à avoir une lisibilité du code et aussi au niveau de persistance.

Merci

[Luckyluke34]

S'il n'y avait qu'une seule façon de faire des logiciels, ça se saurait

Ca ne veut pas dire pour autant qu'il faut s'éparpiller et rester bloqué face à des choix d'implémentation et d'architecture trop nombreux.

Pour avancer, je te conseille de lire un bon tutoriel pas à pas, ou mieux un bon bouquin sur MVC et de suivre fidèlement son approche. Pour les livres, tu en trouveras plus facilement sur un framework MVC en particulier (Spring...) mais ce n'est pas grave.

En ayant déjà appliqué une approche particulière à la lettre, tu pourras ensuite explorer les autres et te faire ta propre opinion.

[hmimoud]

Bonjour,

Merci encore une fois pour ta réponse

Vous savez, je viens déjà d'achever mon application JAVA et au niveau d’exécution ça marche très bien sans problème, un utilisateur normal dira que le travail est achevé et qu'il n'y a aucun problème, sauf qu'au niveau architecture du code, j'aimerais bien apprendre à ce que ça soit professionnel pour ma formation et aussi au niveau de la persistance de l'application.

Ca ne veut pas dire pour autant qu'il faut s'éparpiller et rester bloqué face à des choix d'implémentation et d'architecture trop nombreux.

Mon problème n'est pas vraiment une question de choix comme vous avez dit d'autant que c'est une question d'informations concernant ces architectures.
J'ai déjà trouvé un tuto sur le MVC en JAVA ici, et dans d'autres tutos et voila ce que j'ai pu constater:

1- Modèle: contient les méthodes avec des instructions SQL + les classes métiers.

2- Vue: contient l’interface graphique en SWING uniquement sans actions avec une référence sur le Modèle pour faire des changement (en lecture) sur la vue en cas de changement du Modèle.

3- Contrôleur: contient les ActionListeners des différents composants de la Vue avec une référence vers la Vue (pour récupérer les composant SWING) et référence vers le Modèle (pour appeler les méthodes du Modèles et les contrôler dans les ActionListeners en ecriture).

Concernant mon application voici la "procédure" que j'ai utilisé (et que je ne peux pas encore appelé architecture puisque je ne sais pas si ça en est une ou du moins laquelle) divisé en 3 packages:

1er: (qui peut être le Modèle ou DAO): contient les méthodes(ajouter, supprimer ...) avec instructions SQL.

2ème: (qui peut être la couche métier): contient uniquement les classes métiers (JavaBeans).

3ème: (qui peut être la Vue): contient l’interface graphique SWING ainsi que les ActionListeners qui font des références vers le dit "Modèle" pour appeler les méthodes et les contrôler.

Désormais, je souhaite savoir si cette procédure peut être considéré comme une architecture (MVC ou 3tiers).
C'est vrai que c'est un peu différent de ce que j'ai déjà mentionné juste au dessus sur l’implémentation MVC mais dont je doute de sa justesse.
De même, je ne sais pas si on peut la considérer comme architecture 3 tiers puisque j'en ignore l’implémentation faute d'informations dessus (et que j’espère bien connaitre).
J'essaierai d'appliquer à mon code l'architecture que je trouve la plus proche à dont je suis arriver jusqu'ici puisque je ne souhaite pas faire des changements plus ou moins radicales à mon code.
Si malgré ces précisions je ne trouve pas encore de réponses pertinentes (et là je comprendrais ce sujet est peut être sans réponse en soi), je vais essayer d'appliquer le MVC comme je l'ai mentionné là dessus (si c'est juste) ou bien je ferai migrer mon sujet dans une autre rubriques tels que JAVA ou autres.

Cordialement,

Merci

[Luckyluke34]

1er: (qui peut être le Modèle ou DAO): contient les méthodes(ajouter, supprimer ...) avec instructions SQL.

2ème: (qui peut être la couche métier): contient uniquement les classes métiers (JavaBeans).

3ème: (qui peut être la Vue): contient l’interface graphique SWING ainsi que les ActionListeners qui font des références vers le dit "Modèle" pour appeler les méthodes et les contrôler.

Désormais, je souhaite savoir si cette procédure peut être considéré comme une architecture (MVC ou 3tiers).

Non, car les contrôleurs sont dans la même couche que la vue.

Avec une architecture comme celle-ci, il va probablement être très difficile de substituer une techno UI par une autre (ex : Swing par Awt comme dans le tuto que tu cites en lien) sans réécrire aussi les contrôleurs ou tout au moins copier-coller l'intégralité des contrôleurs, ce qui est contre-productif.

Une architecture en couches consiste juste à éclater les différentes responsabilités de l'application :

• Afficher quelque chose à l'écran
• Aiguiller sur les bons écrans et orchestrer les appels au métier
• Gérer les règles et objets métier
• Parler à la base de données
  ...

Le but est d'avoir des modules/couches (= fichiers .jar, .dll, etc.) facilement substituables, découplés les uns des autres et testables indépendamment.

Si on ne comprend pas ce découpage en couches et ce que fait chaque couche, on ne comprend pas MVC.

[hmimoud]

Bonsoir Luckyluck34,

Je sais bien que ces architectures permettent un découplage en couches, sauf que j'aimerais bien connaitre si les détails que j'ai donné concernant l’implémentation MVC sont justes et aussi avoir quelques détails de l’implémentation JAVA de l'architecture 3 tiers, peu importe la difficulté de changement que je puisse appliquer à mon application, ça sera aussi des informations de plus pour moi et aussi pour les visiteurs du forums intéressés.
Je doutais bien, selon ce que je connait au niveau théorique que, ce que j’avais fait ne correspondait pas à une certaine architecture sinon, je n'aurait pas lancé cette discussion et maintenant j'aimerais bien passer au niveau pratique.
Je crois que le titre de la discussion doit changer et aussi je pense que je me suis trompé de rubriques puisqu'ils n’intègre pas l'architecture 3 tiers.
J’essaierai de poser mon problème dans une autre rubrique en attendant vos réponses.

Merci bien pour vos intérêts

[Cincinnatus]

Bonjour,

Les deux notions citées sont indépendantes :

- le MVC est un pattern de conception d'un logiciel, créé si je me souviens bien dans le but de changer plus facilement la vue. Il sépare donc comme vous l'avez dit tous les deux les données (Modèle), l'affichage (Vue) et les interactions avec l'utilisateur (Contrôleur).


- l'architecture 3-tiers est donc un pattern architectural. Elle concerne le déploiement d'une application sur plusieurs serveurs, typiquement :

serveur Web |----| serveur applicatif |----| serveur de base de données

Ceci permet notamment une meilleure sécurité (seuls les serveurs Web étant directement exposés) et une meilleure montée en charge.