Différence entre modéle 3-tiers et modèle MVC

Bonsoir, j'ai développé une application basé sur le modéle 3-tiers , son fonctionnement se résume en :

http://img7.imageshack.us/img7/4633/architecturem.jpg
- Une application java qui va faire son traitement, enregistre ses résultats dans la base de données.
- Une interface web qui permets à l'utilisateur de consulter ses données (temps réel ou date donnée).

mais la je n'ai pas exactement compris le role de MVC dans ca, ce que je connait c'est que le modele 3-tiers tend a séparer :
-la couche métier.
-la couche présentation.
-la couche accés de données.

Est ce que le modéle MVC est seulement utilisable dans la couche présentation ? avec servlet = controleur, jsp =vue et enfin JDBC= modele?

Le MVC est pattern pour construire des interfaces, donc la couche présentation comme tu l'as fait remarquer. En web avec java on utilise souvent STRUTS ou Spring2 pour réaliser un pattern MVC. C'est souvent le couche métier qui sert de modèle et pas JDBC directement. JDBC te sert à construire ta couche d'accès aux données.

la couche métier c'est celle qui fait les traitements pour la suite les affichers sur mon interface web c ca?

Bonjour

Exemple techno

JSF -> EJB -> JPA
Ou
JSP -> Servlet -> DAO -> JDBC

HTML -> PHP -> ORM ...

On décompose en couche les différents aspects

Dans mon IHM

Mon présentation

print début page..
print CSS ....
Qui appelle mon objet métier ou service
$this.c = new MonObjetMetier(); -> qui appelle mon DAO ou JPA

.....

Bref, c'est simplement de l'encapsulation (MVC)

Un bon exercice, tu fais une page web PHP crado, mélange HTML PHP appel base.
Puis tu fais du refactoring de code.
Tu insères un moteur de template
Tu fais une couche d'accès à la base
Tu fais une couche traitement qui accède à la base
etc...

et tu tendras vers un MVC maison.

Olivier

Le MVC c'est juste pour la couche présentation.
En gros la VUE c'est l'interface utilisateur. Sur la VUE l'utilisateur réalise des actions (écritures, cliques) en web au final cela se traduit des requêtes HTTP.
Le CONTROLEUR traite ses requêtes HTTP et les paramètres et les traduits pour le modèle métier (MODEL) qui va concrètement réaliser le boulot et se mettre à jour.
En suite en web (avec Struts) le CONTROLEUR renvoie d'un nouvelle page (nouvelle VUE) ou une simple validation ou une erreur... avec AJAX tu peux faire une mise à jour de ta VUE.

Bref tu peux faire du 3-tiers sans faire du MVC, c'est ce qui se passe en PHP, ASP.NET (il existe un framework MVC), JSP... il faut en général un framework MVC pour mettre en place le pattern, c'est pas naturel et un peu plus lourd.
Sans MVC, on appel directement le modèle métier dans la vue, ça marche très bien aussi. Après si l'application est grosse on ne peut pas facilement réutiliser le code d'une page à l'autre.

En web il faut noter que la couche présentation est répartie sur le serveur (génération du flux HTML) et sur le poste client (rendu et javascript) bref les fameux tiers sont logiques et pas physique.

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.

Personnellement, j'ai utilisé ca dans mon developpement :
pour la couche vue : JSP
pour la couhe control : servlet
pour la couche métier : un JDBC pour l'accés a la base de données....

normalement l'architecture est bonne non ?
j'ai pas trop compris la diffénrece entre le JDBC et le EJB

Citation:

---

Envoyé par nathieb

Bonjour

Exemple techno

JSF -> EJB -> JPA
Ou
JSP -> Servlet -> JDBC

HTML -> PHP -> ORM ...


Olivier

---

je pense que c'est bon

JDBC est l'API de communication avec une base de données
EJB est bien plus que ça, pour faire simple, on distingue 3 choses :

- les composants session (stateful/stateless)
- les composants message driven
- les entités

les 2 premiers sont un peu dans la même logique, des composants distribués avec des capacités transactionnelles lorsqu'ils sont associés à une unité de persistance, le deuxième étant appelé par un message là où le premier est appelé directement.

le 3ème est un mapping des tables de base de données et permet de convertir le monde SGBDR en objets java (ORM) au travers de l'API JPA.

mais globalement c'est le meme rolen juste que EJB est plus complet et evolué non ?

Moi j'ai utilisé des JSP-->Servlet-->JDBC

Bonjour,

Effectivement, c'est un raccourci, JDBC t'es fourni, donc tu mappes les accès base dans des objets, non ?
Ainsi je pense que si tu veux faire plus propre
On écrit

JSP -> Servlet -> DAO -> JDBC, ce dernier DAO est un des patterns qui te permet de mapper tes accès base de donnée.
Si tu veux évoluer véritablement, tu peux utiliser un ORM (Hibernate, topLink ou eclipse Link) C'est un bon moyen de monter en compétence sur des technos que l'on commence à retrouver même en PHP ;), et je sais de quoi je parle.

Olivier

Dans l'histoire, ce n'est pas le type de techno utilisée qui importe, c'est le découpage.
Tu peux très bien utiliser JSP pour la vue, servlet pour le contrôleur mais il faudrait utiliser un bean pour encapsuler l'accès au données (via JDBC si tu veux, ça marche très bien).
Un autre point, il faut un bean pour représenter les données envoyées à la page JSP si tu veux être en accord avec le pattern MVC.
Pour faire simple :
- un bean qui représente tes données de la page JSP
- une page jsp qui utiliser le bean pour créer le rendu
- une servlet qui reçoit les demandes et fait le "routage"
- un bean spécialisé (qu'on appellera DAO) pour accéder aux données de la base de données

Le premier bean peut encapsuler d'autres objets java qui représenterait des enregistrements structurés d'une table, c'est tout à fait envisageable et très probable.
Un exemple, tu as une table Personne et ta vue veut afficher la liste des personnes.
Ta DAO va donc créer une liste d'un objet Personne (List<Personne>) et ton bean modèle contiendra cette liste.

Code:

---

1 2 3 4 5 6 7 8

class ModeleRecherchePersonne { private String filtreNom; private String filtrePrenom; private List<Personne> list; ... }

---

Dans cet exemple, on suppose que ta vue a prévu deux critères de recherche, un par nom, un autre par prénom.

La confusion vient souvent du fait qu'on confond le modèle métier avec le modèle de la vue.
Dans l'exemple, Personne représente un modèle de données métier (entité en JPA) alors que ModeleRecherchePersonne est le modèle dans le pattern MVC.

Tu vois mieux la logique ?

Je rajouterai juste que le modèle MVC peut-être lourd à mettre en place pour des petits projets, si l'on veut vraiment le respecter. Alors qu'un modèle en couche se met facilement en place. Niveau techno pour un modèle en couche je conseille JPA + (SPRING au choix) + Vaadin (très bon framework de présentation qui permet de ne pas manipuler des htmls ou autre, se comporte comme swing par exemple). Voilà :ccool:

D'accord merci :)

Sinon une autre question svp, pour la conception d'une application pareille, comment dois-je procéder?