Discussion :

[hmimoud]

Bonjour,

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 .

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 une persistance.


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.


Mon problème n'est pas vraiment une question de choix 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 écriture).

Concernant mon application voici la "procédure" que j'ai utilisé 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.

Je souhaite bien savoir si les détails d’implémentation MVC que j'ai donné si haut sont juste et aussi avoir quelques détails sur l’implémentation JAVA de l'architecture 3 tiers.
J'essaierai d'appliquer à mon code l'architecture que je trouve la plus proche à dont je suis arriver jusqu'ici, car, à ce qu'il parait, ce que j'ai fait ne respecte pas une architecture bien définie.

Merci

[noOneIsInnocent]

bonjour

de manière générale, on utilise les frameworks (struts,spring mvc,jsf etc) pour éviter de réinventer la roue
l'architecture MVC a quand même évoluée vers MVC2
Sinon concernant ta question, ton implémentation m'a l'air correcte au détail que je rajouterais un niveau qui permet d’accéder au modèle via des classes de services
Pour avoir les données du modèle tu appelles ces classes de services

[wiztricks]

Salut,

de manière générale, on utilise les frameworks (struts,spring mvc,jsf etc) pour éviter de réinventer la roue
l'architecture MVC a quand même évoluée vers MVC2

Avec Swing, il est plus naturel de construire une architecture "2 Tiers" et de designer l'IHM suivant MVC. Strut/Hibernate/Axis/Spring donnera plus naturellement dans le MVC2 et une architecture 3 Tiers.

Pour revenir à la question du PO

Je souhaite bien savoir si les détails d’implémentation MVC que j'ai donné si haut sont juste et aussi avoir quelques détails sur l’implémentation JAVA de l'architecture 3 tiers.

Lorsqu'on parle de "tiers" on parle d'abord d'une possibilité de répartir les composants applicatifs (et leur charge) sur plusieurs "serveurs" (au sens environnement système, puissance de calcul).

Comme vous avez développé une application Swing, elle sera plutôt 2 Tiers:

• IHM et logique métier s'exécute sur le poste de travail,
• le serveur de base de donnée,

Vous devriez pouvoir exécuter le tout sur un seul poste ou partager le serveur de base de données avec N postes en changeant seulement un fichier de configuration.

De nos jours (et pour simplifier), les composants d'un tiers ont une interface avec les autres tiers qui passe par des protocoles IP. Cette interface réseau est suffisante (mais pas nécessaire) à caractériser/matérialiser ce qu'on appellera un tiers et les "composants" associés.

Quelque soit l'application, à partir du moment ou vous avez des interactions avec des utilisateurs (IHM) il faut définir les relations entre ce qui va être affiché (View), les événements qui déclencheront des mises à jours (Controller) des objets "métiers" (Model).
SWING définit Views et événements associés à des widgets.
Les actions associées à ces événements pourront modifier des objets "métiers". Les attributs d'un objet métier peuvant être affiché dans plusieurs "windows" sous la responsabilité de différentes Views. Comment seront mises à jour ces Views pour refléter un changement sur un des objets du Model?
MVC essaie de répondre à ces questions mais reste un pattern de conception: il permet un découpage des objets de l'application suivant rôles et responsabilités.
Coté réalisation (le design du code) on s'appuie sur d'autres patterns voir par exemple

MVC ou pas est fonction de relations entre Modèle et widgets Swing que vous aurez explicitement construites.
Si ce n'est pas le cas, cela ne vous a pas empêché de réaliser une application qui fonctionne et ce qu'il faut essayer d'apprécier c'est ce qu'on appelle la "dette technique". Autrement dit, est ce que l'évolutivité ou la maintenance de l'application seront plus difficiles que si vous vous étiez appliqué à...
En général, la réponse est "oui" mais dans la pratique, c'est fonction de la taille/complexité de l'application (nombre d'objets, lignes, point de fonctions).

Cordialement,
- W

[hmimoud]

Bonsoir,

Merci wiztricks et noOneIsInnocent pour vos réponses.

Je vais abandonner l'idée de travailler avec MVC puisqu'il doit utiliser un framework chose que j'évite de faire dans mon projet.

Du coup, je vais plus me pencher à utiliser une architecture 3 tiers uniquement.

Comme vous avez développé une application Swing, elle sera plutôt 2 Tiers:

• IHM et logique métier s'exécute sur le poste de travail,
• le serveur de base de donnée,

Pour moi, ce n'est pas une question de choix entre l'utilisation de 2 tiers ou 3 tiers, mais c'est plutôt imposé pour moi d'utiliser l'architecture 3 tiers.

J'aimerais bien découpler mon application sur 3 packages selon le "formalisme" 3 tiers, c'est à dire: "DAO", "METIER" et "PRESENTATION".

Donc, est ce que le découplage suivant est suffisant pour parler d'une architecture 3 tiers, sinon que dois je modifier ici pour qu'elle en soit une ?

"DAO": contient les méthodes(ajouter, supprimer ...) avec instructions SQL.

"METIER": contient uniquement les classes métiers (JavaBeans).

"PRESENTATION": contient l’interface graphique SWING ainsi que les ActionListeners qui font des références vers le DAO pour appeler les méthodes et les contrôler.

J'ai déjà lu ces deux discussions de l'implémentation de l'architecture 3 tiers avec SWING: 1ére et 2éme, sauf que chaque membre donne une réponse différente et en plus il n'y a pas de réponse concrète.
Ce qui me laisse douter, c'est qu'ils y en a qui considèrent que le DAO c'est la base de donnée elle même, physiquement, et que les méthodes qui font extraire les informations de la BD se trouvent dans la couche métier ainsi que d'autres confusions.

Merci

[NextArchitecture]

Il est peut être important d'avoir bien en tête les différentes nominations (n'hésitez pas à me reprendre) :
le modèle MVC est un design pattern. C'est une modèle abstrait de conception informatique, consistant a séparer en couches une application.
Le suivi de ce modèle est maintenant plus que recommandé pour la réalisation d'architecture Web, dont les mécanismes de contrôle et de données sont parfois sensibles, et pouvant nécessiter un grand nombre d'acteurs.

Struts 2 / Spring / Hibernate est une combinaison standard permettant d'appliquer ce modèle abstrait.

Struts 2 permet la gestion de l'affichage utilisateur et du contrôle de format des données ;

Spring permet la gestion du cycle de vie des éléments de l'application ;

Hibernate permet la gestion de l'accès à la base de données.

Chacun de ces éléments peut être supprimé sous réserve de le remplacer par un autre framework / développement spécifique réalisant une tâche semblable.

La DAO consiste en la couche d'accès à la base de données (Data Access Object). Hibernate est ainsi une implémentation de la couche DAO.

Avec ces idées bien en tête, à toi de comparer les frameworks disponibles afin de déterminer la solution d'architecture la plus applicable.

Bon courage !