Architecture d'une application JEE

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 :

http://nsa19.casimages.com/img/2011/...0455963404.jpg

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?

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.

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 ?

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/

Citation:

---

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 ><

Citation:

---

Envoyé par Jimmy_

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.

Citation:

---

Envoyé par DevServlet

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é

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.

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?

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.

Citation:

---

Envoyé par 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.

---

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 :

Citation:

---

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

---

Citation:

---

Envoyé par marouene_

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é ?? :mouarf:

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.

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

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.

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.

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 :mrgreen:)
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 ?

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

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 :mouarf: .

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

Citation:

---

Envoyé par 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 :mouarf: .

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

---

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?

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).

Citation:

---

Envoyé par 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 :mouarf: .

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

---

Pour la dernière remarque, on est typiquement dans le genre d'application PHP, de là à dire que c'est un gros bouzin, c'est un peu excessif... tout dépend de ce qu'on veut faire.
Pour une page à contenu dynamique, c'est très adapté (contrairement à l'architecture MVC, c'est comme si on voulait démolir un mûr avec un canon de 888mm :aie:)

Pour une application conséquente, par contre, ce pattern aide beaucoup...

Bonjour,

Je suis d'accord avec le Post de Obutterlin, qui a souvent d'ailleurs un avis judicieux.
Beaucoup de monde confond l'aspect N-tiers avec celui d'une architecture physique ( machine ).
Le N-tiers est un découpage logique, si en plus tu y introduis des services délocalisés (physique) cela est encore mieux. On colle pas le serveur d'application sur la machine qui héberge la base de donnée.

Pour ce qui est de ton analyse, tu dois nous prouver que chaque couche ou jar, war etc . pourrais fonctionner les uns indépendements des autres.
Bref ma couche authentification (un jar) peux être exportable sur un autre projet sans rien modifié, et cette réflexion pour chaque couche.

Dire que jdbc est une couche est un abus de langage, si tu as des requêtes dans tes servlets c'est donc mal construit.
Normalement on doit pouvoir interroger ton système de persistence sans savoir si c'est du SGBD, du fichier ou du ldap.
C'est la théorie, mais en pratique c'est mieux. car plus maintenable.

Dans les frameworks type, JSF tu es déjà en multicouche un template/ un bean manager (MVC), puis tu peux interroger des EJB qui mappent une couche services ( objet métiers ) qui interroge des objets JPA (qui mappe la base ou autre) bref on pourrais encore découpé. Mais si je remplace une couche par une autre ayant les mêmes signatures de méthodes, et l'application doit toujours fonctionner.

Souvent on expose des interfaces (pas de code)

Les designs patterns sont un bon moyen de comprendre.

Mais j'avoue il faut pratiquer et maintenir pour bien comprendre les affres du "tout dans le même fichier" (vue, base traitement) si si j'en voit encore.

Mais parfois c'est mieux, c'est souvent un compromis entre optimisation et architecture, rien n'est parfait, et à faire des couches de couches, cela devient parfois incompréhensible (code mort)
Bref il faut rester critique.


Olivier

Citation:

---

Envoyé par nathieb

... c'est souvent un compromis entre optimisation et architecture, rien n'est parfait, et à faire des couches de couches, cela devient parfois incompréhensible (code mort)
Bref il faut rester critique.

---

C'est également mon point de vue :ccool:

Il faut rester critique ET savoir s'arrêter à temps ! A force de théoriser, on ne livre plus d'application... :mouarf:

Bonjour,

Bonne conclusion !
:ccool: a force

olivier

D'accord, merci

Donc si c'est juste, je ferai mieux de dire que c'est une application 3-tiers utilisant la plateforme JEE ( je parlerai pas du pattern MVC), avec mon serveur qui alimente ma base de donnée
:ange:

Bonjour,

Oui.

Olivier