Discussion :

[marouene_]

Bonjour, j'ai quelques confusion sur l'architecture d'une application JEE, bon j'ai developpé une application dans l'architecture physique est la suivante :



En gros j'ai deux parties :
* Pour l'alimentation de la base de données, j'ai le serveur d'application qui effectue des tests en continue à partir du serveur des serveurs de tests installé dans le réseau ceci sans intervention du client (un système de monitoring) et qui stocke les résultats dans une base de données.
*J'ai un client qui consulte sur des pages JSP (des courbes etc...selon sa demande ) les résultats des tests effectués à partir de la base de données..Mais il peut pas changer le contenu de la base-----> juste monitoring


Donc voila, j'aimerai comprendre comment bien expliquer cette architecture, pour l'affichage c'est bien une application JEE(Servlet/JSP/JDBC).

Sinon est ce que je dois dire que c'est une application JEE 3-tiers implementant le modèle MVC pour la couche présentation?

[Jimmy_]

Attention à ne pas tout mélanger.

3-tiers est une architecture qui sépare l'affichage, les traitements et les données. Avec de préférence un changement de protocole entre les couches.

MVC est un design pattern, c'est à dire un découpage abstrait de la manière de traiter une requête.

Une application MVC pouvant très bien être découpé en N-tiers ou pas.

Donc à mon avis si tu fais du Jdbc directement depuis ta servlet sans couche d'abstraction, tu n'es ni en MVC ni en 3-tiers.

[marouene_]

J'utilise directement du JDBC pour alimenter la base et je l'utilise aussi pour l'affichage des résultats
Mais normalement je suis dans la norme des applications JEE c'est ca ?

Autrement, mon application sépare effectivement l'affichage du traitement et des données non ?

[marouene_]

D'apès la discussion que j'ai crée ici ca fait un petit moment
http://www.developpez.net/forums/d10...rs-modele-mvc/

Le modèle MVC est lié aux IHM, ce pattern permet de répartir les rôles :

M : représente les données de la vue (un JavaBean)
V : représente la vue (une JSP)
C : représente le contrôleur (interface entre M et V) (une servlet, une action struts...)

Autrement dit :

On affiche une page avec un formulaire.
L'utilisateur saisie des données et soumet la requête au contrôleur.
Le contrôleur récupère et alimente le modèle et traite la fonction demandée (Il peut évidement accéder à des briques métier (EJB ou autre)).
Le contrôleur renvoie une page.

je comprend plus grand chose ><

[DevServlet]

Donc à mon avis si tu fais du Jdbc directement depuis ta servlet sans couche d'abstraction, tu n'es ni en MVC ni en 3-tiers.

Si sa requete est faite dans une servlet, cette requete qui tape dans une base de donnée, resultat recupéré et renvoyé à une jsp pour affichage, pourquoi ce ne serait pas du MVC? Ne perds pas de vue la signification du M pour Modèle (couche de persistence) , Vue (couche de présentation= jsp dans ton cas) et C pour controleur (servlets dans son cas). Pour moi il est dans une archi MVC 3-Tiers.

[marouene_]

Si sa requete est faite dans une servlet, cette requete qui tape dans une base de donnée, resultat recupéré et renvoyé à une jsp pour affichage, pourquoi ce ne serait pas du MVC? Ne perds pas de vue la signification du M pour Modèle (couche de persistence) , Vue (couche de présentation= jsp dans ton cas) et C pour controleur (servlets dans son cas). Pour moi il est dans une archi MVC 3-Tiers.

Effectivement, ma requête se fait dans une servlet comme tu l'as exactement mentionné

[DevServlet]

Ton archi telle que tu nous l'as presentée respecte le MVC, bon mais dans une stricte mesure, les requetes doivent être deleguées à un framework de persistence (JPA, hibernate, etc...), une servlet ne devrait normalement pas avoir connaissance de la notion de requetes, elle fait une demande et on lui renvoit un résultat, la facon dont ce resultat a été traité devrait lui être transparente. Mais bon ce que t'as fait c'est deja pas mal.

[marouene_]

Ah ok, donc j'ai ca normalement :
Pour le M : JDBC
Pour le V : JSP
Pour le C :Servlet
normalement le modèle MVC se limite Ici juste à la partie client et serveur tomcat/base de données , c'est a dire il se limite seulement à l'affichage des résultats ?
Le serveur d'application qui effectue des tests et alimente la base de données n'est pas inclu dans ce modèle mais ile doit l'etre pour le modele 3-tiers?

[DevServlet]

Dans une moindre mesure on peut dire qu'il fait partie de ton modèle, c'est lui qui alimente tes données. Mais bon d'une maniere rigoureuse tu vois à peu près où se limite ton MVC.

[marouene_]

Dans une moindre mesure on peut dire qu'il fait partie de ton modèle, c'est lui qui alimente tes données. Mais bon d'une maniere rigoureuse tu vois à peu près où se limite ton MVC.

D'accord merci beaucoup pour vos conseils, donc en final pour bien expliquer ma solution, je mettrai : une architecture 3-tiers qui implémente la plateforme JEE avec :
- couche présentation qui adopte le pattern MVC ( evidemment celui de JEE)
- couche métier
-couche accés à la base de données

Mais bon une question peut-etre bete , en voyant ca , je ne vois pas une grande différence entre 3-tiers et MVC :

L'architecture MVC

Model View Controller (Modèle Vue Contrôleur) est souvent décrit comme un simple design pattern (motif de conception) mais c'est plus un architectural pattern (motif d'architecture) qui donne le ton à la forme générale d'une solution logiciel plutôt qu'à une partie restreinte.

Les trois parties du pattern MVC sont les suivantes :

1. Model : Le modèle défini les données de l'application et les méthodes d'accès. Tout les traitements sont effectués dans cette couche.
2. View : La vue prend les informations en provenance du modèle et les présente à l'utilisateur.
3. Controller : Le contrôleur répond aux événements de l'utilisateur et commande les actions sur le modèle. Cela peut entrainer une mise à jour de la vue.

L'architecture 3-Tier

L'architecture 3-Tier sépare, tout comme MVC, l'application en trois parties bien distinctes :

1. User interface : La partie présentation de l'application.
2. Buisness logic : La couche métier qui s'occupe du traitement de l'information.
3. Dataaccess : La partie accès et stockage des données

[DevServlet]

Mais bon une question peut-etre bete , en voyant ca , je ne vois pas une grande différence entre 3-tiers et MVC :

Très bonne question, une architecture 3-Tiers indépendamment du contexte est un modèle d'architecture dans lequel 3 couches interagissent, dans un contexte applicatif ils respectent le MVC, mais cependant tu peux très bien avoir un modèle d'architecture 4-tiers qui respectent aussi du MVC, comme par exemple des projets qui utilisent des EJB3, dans une telle arcchitecture on a Vue<=>Controleur<=>Logique Metier (assurée par les EJB3) <=> BD. et donc en conclusion un modèle 3-tiers applicatif implemente le pattern MVC mais tout modèle dans une archi MVC n'est pas en 3-tiers. pigé ??

[Jimmy_]

Pour être valide le design pattern MVC doit quand même respecter les différentes couches. Il ne suffit pas de dire, c'est bon je fais du MVC car j'ai des jsp, des servlets et du jdbc.
Si à coté je dépile mon resultset Jdbc dans la servlet, ou alimente mes champs d'affichage au milieu des appels Jdbc, ce n'est pas bon.

Ensuite le N-tiers doit être déployable sur différent serveur. Si la base de données est sur le même serveur que le serveur d'application, ce n'est pas du N-tiers.

[marouene_]

Ah d'accord donc les deux sont des architecures logiques? je pensais avant que le modèle 3-tiers est bien physique

[DevServlet]

Non pas forcement, toutes les couches peuvent très bien physiquement resider sur une meme machine physique. Concretement qu'est ce qui t'empeche d'installer ton application et sa base de donnée sur la même becane? rien du tout.

[Jimmy_]

Sauf que si physiquement tu as tout sur le même serveur, ce n'est plus vraiment du N-tiers. Puisque par exemple une intrusion sur ton serveur expose directement tes données. Alors que sur une vraie architecture n-tiers, un intrus qui arrive par exemple sur ton serveur de présentation peu casser des pages html, mais doit attaquer deux autres serveurs, avec des protocoles différents avant d'arriver aux vraies données.
L'objectif de chaque couche est de proposer des services et de se rendre indépendant des autres, en vérifiant les données qui arrivent de la couche supérieur.

[OButterlin]

C'est un sujet qui fait débat.

Certains voient une application 3-tiers comme faisant référence à 3 serveurs

1- le poste client avec son navigateur (Firefox bien sûr )
2- le serveur d'application
3- le serveur de base de données

les autres voient les tiers comme des couches logiques :

1- une couche présentation
2- une couche traitement/métier
3- une couche accès aux données / persistance

Normalement, c'est le cas 2.

Ce 3-tiers et MVC (ou MVC2) sont très proches, avec des petites subtilités que le monde des EJB met bien en évidence.

Le MVC est lié à l'IHM :
M pour le modèle (le bean qui contient les données de la vue)
V pour ce qu'on voit (la JSP dans ton cas)
C pour le contrôleur qui reçoit les actions

La couche de traitement serait une EJB stateful ou stateless
La couche persistance se ferait via JPA et les entity

C'est plus clair ?

[marouene_]

Ah d'accord, donc à prioris si je me trompe pas , le modèle 3-tiers est un modèle qui tend à séparer :
-couche présentation----> Client

-couche traitement ------> Serveur d'application

-couche donnée ---------> Serveur base de données.

Le MVC est un pattern utilisé pour construire les interface homme machine, donc à prioris on se limite à la couche présentation.

dans mon cas, j'ai utilisé JSP -> Servlet -> JDBC dans comme je l'ai montré dans l'architecure précédente, je dois etre dans les normes d'une application 3-tiers( oublions le fait que le serveur de base de donnée est lié au serveur Web) et MVC

[Jimmy_]

Le sujet fait débat certes, mais logique ou physique, si tu ne fais pas une isolation minimal entre ta présentation et tes données, via un quelconque mécanisme. On ne peut pas parler de n-tiers, ni de MVC, ni de rien du tout.
Ca sera juste un gros bouzin .

J'ai même vu dans mes audits, du jdbc en scriptlet dans les jsp.

[marouene_]

Le sujet fait débat certes, mais logique ou physique, si tu ne fais pas une isolation minimal entre ta présentation et tes données, via un quelconque mécanisme. On ne peut pas parler de n-tiers, ni de MVC, ni de rien du tout.
Ca sera juste un gros bouzin .

J'ai même vu dans mes audits, du jdbc en scriptlet dans les jsp.

oui je confirme, mais pour mon application en tenant compte de la séparation logique, l'architecture que je vous ai montré, est normalement de type 3-tiers ( client/application et base de donnée) et MVC ( pour l'utilisation de servlet/jsp/Jdbc) , pour le serveur de test qui alimente ma base de donnée je l'inclu dans l'architecure comme s'il faisait parti du système 3-tiers?

[OButterlin]

On peut voir l'alimentation de ta base de données comme un tiers également, on serait dans du 4-tiers.
Pour le MVC, je ne peux pas répondre, je ne sais pas ce que tu as prévu pour répondre à ce pattern.
Dans l'absolu, on peut le faire avec une servlet pour le contrôleur, la JSP pour la vue et un bean pour le modèle. JDBC servant à accéder aux données, je le mettrais dans un autre bean (pattern DAO).