Confusion 3-tiers et MVC

Bonjour à tous,

voilà j'ai une question existentielle : est-ce qu'une architecture MVC est une architecture 3-tiers ?
Ou MVC fait simplement partie de la couche présentation ?

Parce que je lis des trucs dans les tuto developpez et sur wikipedia qui ne sont pas tout à fait d'accord, du coup je m'embrouille.

L'un intègre MVC dans la couche présentation et l'autre fait un "comparatif" entre les 2.
Comment peut-on comparer une chose avec une partie d'elle même ? D'où ma question.

Je sais que ce sont des principes et que la pratique ce n'est pas toujours raccord avec la théorie mais c'est pour une présentation donc j'ai besoin d'exposer la théorie.

Bon je vais t'expliquer mon point de vue sur la chose. Mais ces paradigmes d'architectures sont, comme tu le dis, des points de vues théoriques. Ils sont adaptés dans la pratique et prêtent encore à des débats sur leur bonne utilisation (on pourrait y rajouter PAC, M-V-VM dans le monde .NET, etc etc ...).

Je résumerais la situation comme ça (de ce que j'ai compris) :
- L'architecture MVC pour une appli avec IHM : Son principe est cyclique puisque d'une action dans la Vue, le Controleur agit en conséquence. Ce Controleur va chercher les informations dans le Modèle qu'il envoie à la Vue pour se mettre à jour.
- L'architecture 3-tiers : Son principe est plus par couche. La Présentation signale une action à la couche Métier qui elle s'occupe des traitements. La couche Métier va chercher les données au sein de la couche Données. Les Données sont renvoyées à la couche Métier. La couche Métier renvoie les nouvelles informations à écrire au niveau de la couche Présentation.
- L'architecture 3-tiers avec MVC pour la présentation : L'action de l'utilisateur est récupérée par la Vue qui demande l'action au Controleur. Le Controleur accède à la partie Métier pour avoir accès à la logique de l'application. La partie Métier peut avoir accès aux données de BDD ou autre par l'intermédiaire de la partie Donnée. Grâce à ce traitement, le Controleur peut alors formater le Modèle via les données de la partie Métier et l'envoie à la Vue. On a donc bien le modèle MVC au sein de la couche Présentation de l'architecture 3-tiers.

Donc, pour moi, MVC et 3-tiers sont bien deux architectures différentes mais qui peuvent être couplées ensemble d'où ce méli-mélo que l'on peut trouver.

D'accords, alors si on regarde avec le fonctionnement de JSF par exemple, la vue ce sont les pages jsf (xhtml, jsp...), et le contrôleur ainsi que le modèle correspondent au ManagedBean ?

En schématisant 3-tiers et MVC ça donnerait quelque chose comme ça:

< Image externe plus disponible > (d'où l'intérêt d'utiliser le bouton trombone pour ajouter des images !)

slt! je trouve ce débat passionnant.
Merci à toi Robin56 pour la solution proposé. j'avoue que je ne comprenait pas, moi aussi la nuance entre ces deux architectures. et si vous voulez bien continuer à nous éclairer je voudrais savoir : "comment savoir quel architecture utiliser entre ces deux architectures très ressemblant?", "quel architecture est meilleur?"
merci!

Citation:

---

Envoyé par dihonson

"comment savoir quel architecture utiliser entre ces deux architectures très ressemblant?", "quel architecture est meilleur?"

---

On ne peut pas vraiment dire qu'une architecture est meilleure qu'une autre. Elles ont toutes leurs avantages et leurs lourdeurs également.

L'avantage du MVC est de bien découper les problématiques de contrôle de l'IHM. L'avantage du 3-tiers est de bien découper les problématiques vis à vis de l'accès aux données. Le mieux serait donc de coupler les deux.

Ainsi, ça donne la chose suivante :
- les contrôles de bases d'IHM peuvent être réalisés dans la vue
- le formatage des données et la récupération des actions utilisateurs sont gérés dans le contrôleur
- le métier peut réaliser les contrôle plus orienté données et établir un formatage aussi des données bruts.
- les données sont séparées de la couche métier pour permettre de sécuriser au plus bas niveau (contrôle des accès base, etc...) par l'utilisation de DAO par exemple.

Évidemment toute architecture a un coût de mise en place. La plupart des frameworks désormais le gère de base et facilite donc ces fonctionnements en couche.