MVC et les differentes couches.

est ce que l'architecture representant un Framework ou plusieurs c'est-à-dire "couche présentation"(UI) , "couche service"(services layer) , "couche persistence"(persistence layer) et "couche métier"(business layer) ont une relation avec le MVC ??
-est ce que le View est bien la couche présentation?
-est ce que le Model est bien la couche métier?
-est ce que le Controller est bien la couche persistence??ou services?

sortez moi du doute s'il vous plait.
une atre chose , pour la cinématique d'une requete , elle passe par le dispatcher servlet qui delegue la request au controlleur , puis un modelandview retour au dispacther qui envoi à la viewresolver la response avant d'afficher la reponse final.

est ce que le viewresolver et le controlleur et le model de cette cinematique sont bien le 'M' le 'V' et le 'C' de cette cinématique??
merci beaucoup pour votre aide.

d'aprés les recherches que j'ai effectué :

la Vue représente la couche présentation(tout ce qui est action sur l'interface).
le Controlleur(gestion de la syncronisation entre la Vue et le Model) représente la couche services (dite métier)(ce qui est class et .
le Modél(traitement des données et interactions avec la base de données) représente la couche persistence(DAO et hibernate).


et dans les request envoyé par le user et dispatcher par le dispatcher servlet se sont bien les model , controleur et view de MVC qui sont impliqué dans la cinématique , bref c'est la meme chose.

si ya un truc qui m'échape dites le moi svp.

Au niveau de la définition du modèle MVC, différentes interprétations circulent.
Pour ma part :

V : représente l'IHM (pages JSP, composants swing etc...)
C : représente le contrôleur appelé par l'IHM pour interagir avec le Modèle (M)
M : représente les "données" de la vue

L'interaction avec le modèle "métier" se fera dans le contrôleur, éventuellement dans le modèle dans certains cas d'initialisations.
En résumé, pour moi, la couche métier n'est pas le modèle du MVC, elle a une portée plus générale, fonctionnelle.

ok merci pour votre reponse donc le doute que j'avais sur la couche métier est reglé , la couche services c'est celle qui relie la couche présentation avec la couche persistence , et donc selon votre explication la classification de couche selon le MVC pattern : le V en premier le C en milieu puis le M qui est en relation avec la base de donné, sinon je crois que le V puis le M puis le C (car vous avez dit que le model réagi selon les changement de la Vue).

C'est le "C" qui est en relation avec ce que tu appelles "la couche Service".

Pour expliquer autrement :

On va assimiler la couche service à la DAO (Data Access Object).
Le contrôleur (C) appelle le/les DAO pour rechercher les données de la base de données et les appliquent au modèle (M) lié à la vue (V).

Imaginons que les DAO ramènent des classes qui sont des entités (JPA).
Il n'en demeure pas moins que ces entités seront intégrées à un objets représentant les "données" de la vue.

En struts 1 (je ne sais pas si tu connais), on a un découpage MVC fort.
La partie modèle (M) correspondrait à la classe étendant ActionForm.
Elle contiendrait une (ou plusieurs) classe entité mais cette entité serait exposée à la vue (V) par l'ActionForm.
C'est plus clair ?

oui , plus ou moins (bon je n'ai pas encore decouvert struts) mais vous avez dit qu'on assimile la DAO à la couche services or dans quelque shcéma c'est pas le cas et ceci m'embrouille les idées un peu .
c'est qu'ils mettent la DAO dans la couche persistence, d'autre coté j'ai bien compris la cinématique que vous m'avez expliqué mais est ce que j'ai tors si j'assimile la couche présentation à la vue , c'est des fois je vois que les requetes envoyé par l'utilisateur sont reçu par le controlleur , et je vois dans d'autre shéma que la vue est (couche présentation ) est liée directement au client.j'éspére que vous m'avez compris mon doute.merci bcp d'avance.

voilà mes schéma comme suit.

Le schéma 5 est la meilleure représentation du modèle MVC.

Pour la couche service, on y trouve souvent plus que juste une logique DAO, on peut voir le service comme un élément "frontal" du fonctionnel d'une application (mais il est vrai qu'on peut y rattacher d'autres notions)

ok merci beaucoup pour votre aide et pour votre pacience.