Discussion :

[kryptong]

Bonjour les amis !!
Bon voilà , je veux faire une application 3 tiers , mais je suis nouvelle à cette architecture et après quelques recherches et lectures , j'ai trouvé quelques points qui ne sont pas clairs par exemple : ADO.net doit on l'ajouter dans la couche DAL ou bien dans la couche BO ?

Merci d'avance

[Invité]

Un petit article sur l'introduction au développement en couches pour bien démarrer.

Oui. ADO.Net c'est pour l'accès aux données donc tout ce qui est extraction et édition de données avec communication directe avec la base de données doit être dans la couche d'accès aux données (DAL : Data Access Layer).

[kryptong]

Un petit article sur l'introduction au développement en couches pour bien démarrer.

Oui. ADO.Net c'est pour l'accès aux données donc tout ce qui est extraction et édition de données avec communication directe avec la base de données doit être dans la couche d'accès aux données (DAL : Data Access Layer).

Je viens de faire un coup d’œil rapide au lien que tu m'a donné , le problème c'est que dans un autre site , c'est mentionné que la partie concernant les requêtes sur la base de donné sont intégrées dans la couche Metier alors que dans le lien que vous venez de me filer c'est dans la couche DAL ?

[Invité]

Je viens de faire un coup d’œil rapide au lien que tu m'a donné , le problème c'est que dans un autre site , c'est mentionné que la partie concernant les requêtes sur la base de donné sont intégrées dans la couche Metier alors que dans le lien que vous venez de me filer c'est dans la couche DAL ?

Tout dépend de quelle architecture il s'agit. Tu peux donner le lien du site dont tu parles ?

[damienolive]

Bonjour,

En effet, l'architecture que tu vas utiliser va dépendre de l'application a développer, des spécificités et des besoins métiers.
En principe, il est déconseillé de mettre dans une même couche le métier et l'accès à la couche de données.
C'est pour cette raison que la couche BLL (business logic layer) et la couche DAL (data access layer) sont deux couches bien distinctes.

Imaginons que les deux couches n'en soient plus qu'une et qu'un jour tu ais à changer ta base de données (migration vers un autre système ou autre sgbd), tu seras alors très lié avec ton métier car tout sera contenu au même endroit et tu devras adapter ton métier à tes données.

D'ailleurs, lorsque tu auras saisi le principe de base de l'archi 3-tier, je t'encourage à regarder la mise en place d'interfaces qui permettent de découpler encore plus les couches entre elles.

[kryptong]

Tout dépend de quelle architecture il s'agit. Tu peux donner le lien du site dont tu parles ?

C'est ici http://nicolas-bede.fr/book/microsof...ness-ou-metier
Je croyais que l'architecture 3tiers est la même pour tous , mais selon toi, il y a différentes manières de la faire c'est ça ?

[damienolive]

Regarde ce lien, il est vraiment bien fait et permet de comprendre facilement le principe de couches dans les architectures :
http://immobilis.developpez.com/arti...ouche-asp-net/

L'architecture 3-tier, en règle générale c'est UI, BLL, DAL (interface, métier, accès aux données).

[Invité]

L'article et celui que j'ai fourni parlent de la même chose c'est à dire d'une architecture 3-tiers. Les deux articles utilisent un découpage en 3 couches :

• UI : interface utilisateur
• DAL : Data Access Layer, couche d'accès aux données
• BLL : Business Logic Layer, couche (métier ou logique métier)

Les 3 couches sont référencées de la même manière dans les 2 articles : UI <-- BLL <-- DAL (où <-- signifie référence)

La seule différence entre deux articles est au niveau de la couche DAL : ton lien utilise Entity Framework (donc un ORM) et celui de Thomas (le lien que j'ai fourni) utilise la "pure" ADO.Net (aucun ORM).

Sinon je te signale l'article de Thomas est correct de A à Z par contre le lien que tu as fourni merde à cet endroit :

Pour ce faire, nous allons créer des classes « miroirs » de nos tables dans le dossier Objects. Ainsi, l’IHM pourra travailler avec les objets « miroirs » de METIER tandis que METIER pourra directement travailler avec des objets de la DAL (via LINQToEntities).

Il duplique les classes générées par Entity Framework avec des classes « miroirs ». Ce qui n'est pas vraiment facile à maintenir parce que si tu as 100 entités dans ton modèle EF tu auras à faire 100 classes « miroirs » et de plus vu que EF ne s'occupe de la mise à jour de ces dites classes alors pour toute modification d'une entité dans le modèle EF tu dois répercuter manuellement cette modification dans la classe « miroir » associée.

Bref depuis la version 4 de Entity Framework il est possible de générer des objets POCO (qui peuvent bien représentés ces classes « miroirs » dont parle ton tutoriel) et aussi une nouvelle approche est née celle appelée Code First. Avec ces deux solutions il est possible de rediriger les objets POCO dans le dossier Objects (confère ton tutoriel) ou via l'approche Code First créer directement ces classes dans ce même dossier.

Dans tous les cas je te suggère de ne pas suivre ce tutoriel. Si tu utilises EF comme ORM alors pense à la génération des objets POCO ou utilise l'approche Code First.