Technologie 3-tiers : eclaircissement

Bonjour à tous,
après avoir lu pas mal d'articles la-dessus j'aimerais avoir quelques informations sur la technologie que l'on nomme de 3-tiers.


D'après ce que j'ai compris
- premiere couche = la page web , avec son formulaire
- deuxieme couche = le code behind et les classes qui gèrent les évènements
- troisieme couche = les procédures stockées qui gèrent les données

j'aimerais avoir confirmation...

Je suis en même temps sur le site de wikipédia la mais je butte un peu sur ce langage purement technique.

Etant en stage, j'utilise apriori les couches que je vous ai énoncé mais j'aimerais un peu d'éclaircissement.

Je voudrais par exemple être sur de mes couches et que quand on parle de technologie 3 tiers on ne parle pas d'outil physique. En ce sens je ne comprends pas bien comment on peut séparer la couche dialogue et la couche métier.

Merci par avance pour vos réponses.
@+,
Tid.



Je tiens à préciser que google n'a pas été mon ami car il s'est montré trop technique et n'a pas pris en compte mon coté 'voudrait des explications claires'...

Idéalement une architecture 3 couches est séparée dans 3 projets différents.
La couche UI (ASP.NET dans ton cas) appelle la couche business par l'intermédiaire d'une facade (design pattern) dans la couche business.
La couche business est responsable du traitement métier en général (validation des données, gestion de la sécurité) et se base sur la couche d'accès aux données pour enregistrer et récupérer des entités de la source de données.
Les entités sont stockées dans une assembly séparée (toujours idéalement) et elles se promènent dans l'application au travers des différentes couches.
Tu peux aussi distinguer entités métier (business) des entités data (accès aux données). Dans ce cas, c'est la couche business qui se charge de traduire les entités data en entités business. Cela te permet d'avoir une couche d'accès basée sur le MPD et une couche business basée sur le MCD correspondant.

On peux aussi intercaller une couche de service (web service, WCF, etc) entre la couche business et la couche UI. Dans ce cas, tu peux décider que le service fasse office de facade ou conserver une facade au niveau business. La deuxième solution augmente le découplage.

Bonjour Tidus,
ta question est intéressante et je trouve aussi que l'on manque d'informations à ce sujet pour savoir comment, a priori, bien faire les choses.

Si tu es à l'aise en anglais, je te conseille vivement cet article.
http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416

Je me suis beaucoup appuyer dessus pour développer en asp.net.
Développer en n-tiers est un concept de programmation très utilisé lorsque l'on développe en classe.
Cela consiste à découper en plusieurs couches chaque partie.

Pour ma part, maintenant, en asp.net, je développe un projet dans lequel j'ai une DLL et un site web.
Dans ma DLL,
j'ai 3 couches:
Couche d'accès aux données
Couche d'objet
Couche Métier

Pour faire simple:
la couche d'accès aux données, comme son nom l'indique permet d'instancier des objets de ma couche d'objet en exécutant les requêtes SQL sur la base de données.
La partie métier me permet de faire appel au méthodes de création d'objets de ma classe d'accès aux données, mais tu peux y ajouter des règles, de la sécurité...

Enfin, dans ma partie site web, je référence ma DLL, et je ne fais qu'appel à ma classe métier pour avoir mes objets.
De plus en ce moment, j'utilise bcp les webservices qui font appel à ma classe métier. En effet j'utilise maintenant bcp le javascript coté client. 'fin c'est un autre sujet.

Personnellement, c'est comme ca que je travaille maintenant mais il existe d'autres manières de faire.

J'espère avoir été clair

Je plussoie pour le lien..

en fr, tu as le cours suivant :
http://plasserre.developpez.com/v5-10.htm

l'exemple 1 correspond a une architecture "standard" (ui, bll, dal)

Sinon, juste pour ajouter mon grain de sel, j'utilise un decoupage en 4 couches, (5 avec la couche service) , avec une couche core commune a toutes les autres couches contenant la gestion des fonctionnalites transverses (log, securite, etc...), chaque couche residant dans une assembly a elle.

L'interet, c'est d'eviter a certains la tentation de faire glisser petit a petit du code de la dal vers la bll ;)

Citation:

---

Envoyé par pvialatte

l'exemple 1 correspond a une architecture "standard" (ui, bll, dal)

Sinon, juste pour ajouter mon grain de sel, j'utilise un decoupage en 4 couches, (5 avec la couche service) , avec une couche core commune a toutes les autres couches contenant la gestion des fonctionnalites transverses (log, securite, etc...), chaque couche residant dans une assembly a elle.

---

C'est une architecture 3 tiers standard alors. Si une couche est commune à toutes les autres, ça ne peut pas être une couche, j'appelerais ça un module (mais je chipote). ;)
Pour les problématiques tranversales, je fais de l'orienté aspect pour plugger des comportements sur des méthodes sans avoir à toucher aux différentes couches.

Bonjour,
et déjà merci pour ces réponses : c'est beaucoup plus clair.

En s'intéressant plus a fond à l'asp.net
J'ai réalisé une solution de 2 projets :
- le site en lui même
- ma bibliothèque de classe

Cependant dans le site en lui même, ayant débuté l'asp.net avec ce projet, j'utilise des gridview qui appelle directement des procédures stocké (appelle de la couche acces aux données par la couche presentation)
J'utilise cependant des object comme : les listes déroulantes qui utilisent mes object et des méthodes du style 'afficheNom' 'afficheIdpourValue'

J'aimerais savoir si ce type de projet (assez mal organisé certes) peut etre considéré comme utilisant la technologie 3-tiers.

@Promesses : je ne comprends pas bien comment tu peux insérer dans ta .DLL
la couche présentation qui est logiquement sur ton site et présente les idées à l'utilisateur justement !

Cordialement,
Tid.

Citation:

---

Envoyé par Tidus159

@Promesses : je ne comprends pas bien comment tu peux insérer dans ta .DLL
la couche présentation qui est logiquement sur ton site et présente les idées à l'utilisateur justement !

---

Euh excuse moi mais j'ai pas compris ta requête :oops:

Citation:

---

Envoyé par Promesses

Dans ma DLL,
j'ai 3 couches:
Couche d'accès aux données
Couche d'objet
Couche Métier

---

Je te pose la question sur cette partie de ton post :p

[edit] 3 couches sans parler de la couche présentation je pense que la toi tu utilises une technologie donc 4-tiers ?

Citation:

---

Envoyé par SaumonAgile

Si une couche est commune à toutes les autres, ça ne peut pas être une couche, j'appelerais ça un module (mais je chipote). ;)

---

Chipotaaage !!!

c'est une couche, mais une couche transverse :mouarf:

Citation:

---

Envoyé par Tidus159

Je te pose la question sur cette partie de ton post :p

[edit] 3 couches sans parler de la couche présentation je pense que la toi tu utilises une technologie donc 4-tiers ?

---

Je t'avoue que je ne suis pas à l'aise avec ça.

Mais la "couche d'objet" ne sont en fait que les classes d'objet donc je sais pas si c'est vraiment considéré comme une couche.

Ma couche d'acces aux donnés instancie des objets, et ma couche métier fait appel à ma couche d'accès aux données pour renvoyer mes objets.

En tout cas merci à tous pour ces réponses! Je crois que j'ai encore des progrès à faire au niveau de la gestion de mes couches mais au moins c'est nettement plus clair à présent.

Cordialement,
Tid.
[résolu]