Discussion :

[marouene_]

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


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

[NicoL__]

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.

[marouene_]

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

[nathieb]

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

[NicoL__]

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.

[OButterlin]

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.

[marouene_]

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

[marouene_]

Bonjour

Exemple techno

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

HTML -> PHP -> ORM ...


Olivier

je pense que c'est bon

[OButterlin]

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.