Conception trois tiers (3-tier)

**Gaetch** · 27/05/2009, 11h04

Bonjour,

je voudrais apprendre à concevoir correctement des application en trois tiers et donc s'il existait des tutoriels dur le net j'ai cherché un peu mais pas trouvé quelque chose de très concluant.

J'aurais voulu savoir aussi les avantages et inconvénients du 3-tiers par rapport au modèle vue-contrôleur. Je précise que je fais mes petites recherches sur le net de mon côté mais c'était pour ouvrir une discussion.

**Metafire18** · 27/05/2009, 11h47

Quelques éléments de réponses :
http://dico.developpez.com/html/3020...Controller.php
http://plasserre.developpez.com/v5-10.htm

Apparement le 3-tier et l'architecture MVC sont un même et unique concept

**Hephaistos007** · 27/05/2009, 12h30

Envoyé par Metafire18

Apparement le 3-tier et l'architecture MVC sont un même et unique concept

Disons plutôt que ce sont des notions différentes, mais qui s'accommodent bien l'une de l'autre.

**rakakabe** · 27/05/2009, 13h29

Correction apres

Envoyé par Metafire18

Apparement le 3-tier et l'architecture MVC sont un même et unique concept

. Je suis pas si sur !

3-tier et MVC font partie de la famille architecturale en 3 couches.
La principale difference entre 3-tier et MVC, a mon avis est leur domaine d'intervention :

- 3-tier : se veut etre generaliste et repartie, mais s'interprete differement selon la situation. Exemple :

Client Leger, Serveur d'Applications, Serveur de Donnees;
Couche presentation, couche processur metier, couche support de donnees;
Couche modele, couche vue, couche controleur -> MVC ????.

- et MVC se destine surtout pour les applications interactives (donc generalement les IHM). On le trouve souvent dans les bibliotheques graphiques : Qt, Swing, MFC (a verifier bien sur

). D'ailleurs, son origine a ete le pattern Observer.

**Metafire18** · 27/05/2009, 13h32

Je sort cette info du dico des développeurs

:

Définition de MVC
Model-View-Controller
Modèle d'architecture qui cherche à séparer nettement les couches de présentation (UI : User Interface), métier (BLL : Business Logic Layer) et d'accès aux données (DAL : Data Access Layer). Le but étant d'avoir une dépendance minimale entre les différentes couches de l'application ; ainsi les modifications effectuées sur n'importe quelle couche de l’application n'affectent pas les autres couches.
• Modèle – Encapsule le cœur fonctionnel de l'application, le domaine logique.
• Vue – les données sont envoyées, par le modèle, à la vue qui les présente à l’utilisateur.
• Contrôleur – reçoit les données et les transmets au modèle ou à la vue.
Une telle architecture est communément appelée architecture 3-tier ou à 3 niveaux.

**Hephaistos007** · 27/05/2009, 14h09

Envoyé par Metafire18

Je sort cette info du dico des développeurs

:

Le dico des développeurs n'est pas l'autorité suprême qui fais la pluie et le beau temps en informatique.

Le n-tier (et a-fortiori le 3-tiers) fait partie d'un style architectural général de référence appelé layered architecture, ou architectures en couches en bon français. Comme tout style architectural, elle prescrit des règles. En l'occurrence, il est stipulé qu'une couche ne peut communiquer qu'avec ses couches adjacentes. Après, libre à chacun de choisir le nombre de couche et les responsabilités de chacune des couches. A titre d'exemple, dans le cadre des SI, on parle souvent de 3 couches, ayant respectivement pour responsabilité la présentation, le métier, et les données. Dans le cadre des réseaux par exemple, il y a le modèle OSI constitué de 7 couches, ayant les responsabilité que l'on connaît. Etc.

Le MVC est un pattern architectural certes, mais ne respecte pas le style layered architecture. La preuve, c'est que la vue communique directement avec le modèle, sans passer par le contrôleur :

**Metafire18** · 27/05/2009, 14h13

Envoyé par Hephaistos007

Le dico des développeurs n'est pas l'autorité suprême qui fais la pluie et le beau temps en informatique.

HS: Quelle désillusion!

**Bluedeep** · 27/05/2009, 16h11

Bon, pour commencer il y a confusion ici entre architecture n-tier et n-layers.

Uen n-tier est toujours n-layer, mais rien n'impose à une n-layer d'être n-tier.

n-tier : architecture "répartie"
n-layer : architecture en couches (pour moi la seule envisageable dans tous les cas de figures d'application complète).

Une architecture n-layers dont on répartie physiquement les couches devient une n-tiers.

**Hephaistos007** · 27/05/2009, 17h11

Envoyé par Bluedeep

Une architecture n-layers dont on répartie physiquement les couches devient une n-tiers.

Oui, c'est exact. Tu fais bien de préciser cette distinction.

**rakakabe** · 27/05/2009, 18h00

Envoyé par Hephaistos007

Le MVC est un pattern architectural certes, mais ne respecte pas le style layered architecture. La preuve, c'est que la vue communique directement avec le modèle sans passer par le contrôleur

+1000

, j'ai oublie le principe des couches, et confondu n-couches et n-tiers

.

**wiztricks** · 27/05/2009, 23h31

MVC permet de répartir les responsabilités de différents modules applicatifs.

n-Tiers permets de répartir/distribuer les traitements (déploiement) sur plusieurs systèmes.

Une application des clients lourds qui accèdent à une base de donnée derrière un serveur peut être "MVC" mais ne pourra être déployée que sur 2-tiers.
(en supposant que les clients ont un accès direct à la base).

- W

**Gaetch** · 28/05/2009, 08h25

Au temps pour moi je parlais de l'architecture en 3 couches alors (même si on m'a toujours appris que ça s'appelait 3-tiers) avec les couches présentation, métier et données.

**Bluedeep** · 28/05/2009, 09h23

Envoyé par Gaetch

Au temps pour moi je parlais de l'architecture en 3 couches alors (même si on m'a toujours appris que ça s'appelait 3-tiers) avec les couches présentation, métier et données.

C'est une erreur (génante) qu'on lit fréquemment (y inclut sur Wikipedia si on cherche l'article sur les 3-tier il me semble).

Donc en résumé une apppli peut :

- être n-layer (je dirais même "doit")
- si n-layer, être m-tier (dans ce cas m <= n ).

Exemples concrets :

- 1-tier / 3-layer :
Application client lourd stand-alone avec base de données locale,mais bien écrite, comprendra :
- Presentation Layer
- Business Layer
- Data Access Layer

- 2-Tier/3-Layer :
Application client lourd classique client-serveur bien écrite :
les même 3 couches que précédemment , mais DB sur un serveur séparé.

- 3-Tier/3Layer :
Cas général des appli web si pas écrites "avec les pieds" (style SQL dans code behind).

Cas des grosses appli client lourd (ou client léger) avec une couche server d'application intérmédiaire.

Exemple :
-client lourd + serveur appli + serveur DB (3-tier)

Plus des variantes (pas exemple le cas des appli à client mixte (web + lourd) qui peuvent se présenter comme suit :
-client léger -> serveur web -> serveur appli > serveur DB
-client lourd -> serveur appli (le même) -> serveur DB .

Dans le cas des grosses appli, le 5-6-7 tier, ou plus si affinité

, n'est pas rare.

**Gaetch** · 28/05/2009, 10h11

Merci beaucoup pour ces explications BlueDeep

De toute façon, si elle est bien pensée et programmée, une application n-layers peut être convertie de 1-tier à n-tiers facilement je suppose ?

**Bluedeep** · 28/05/2009, 10h27

Envoyé par Gaetch

Merci beaucoup pour ces explications BlueDeep

De toute façon, si elle est bien pensée et programmée, une application n-layers peut être convertie de 1-tier à n-tiers facilement je suppose ?

Absolument.

- dans le cas du passage de 1-Tier à 2-Tier, c'est normalement immédiat (sous réserve des questions d'authentification).

- le cas du passage 2-tier -> 3-tier est un peu plus délicat, car il faut rajouter une couche de communication (facile en .Net, je suppose facile aussi en technos "java"). Dans ce cas typiquement, on centralise les traitements métiers (il peut y avoir plusieurs raisons pour le faire : un des cas typiques est la centralisation de traitement métier lourd, un autre est de pouvoir provoquer un feedback vers tous les clients connectés d'une modif induite par l'un deux).
Les contraintes d'authentification peuvent parfois venir compliquer un peu les choses (si il y a nécessité d'authentifier de "bout en bout").

- le cas du passage 3-tier -> 4tier (et plus) est similaire au cas 2-tier-> 3-tier. On l'utilise par exemple lorsque les traitements métiers d'une appli web sont lourd et dans ce cas on laisse un "frontal web" qui fait pas grand chose (générer les pages et la présentation des données) et derrière un serveur d'appli qui se charge du "vrai boulot".

**Gaetch** · 28/05/2009, 10h50

Et donc pour en revenir à ma question initiale, connais-tu un bon tutoriel ou un cours pour apprendre à bien développer une application en 3-layers ? A bien séparer les différentes couches, à bien définir qui doit faire quoi. Par exemple je voudrais développer des programmes qui seront liés à une base de données mais cette base pourra changer (on pourra passer d'une base Oracle à une base MySQL par exemple) ou encore l'aspect graphique du programme pourra être modifié sans que ça change les traitements. C'est bien le but de l'architecture en couche n'est-ce pas ?

**Bluedeep** · 28/05/2009, 10h54

Pour ma part, un document que je considère un peu comme une bible sur la question, c'est celui ci : http://cid-410e76c6390c7090.skydrive...chGuide2.0.pdf

Même si il est très "microsoft" les principes sont parfaitement applicables quelque soit la techno utilisée.