Combiner le MVC et l'architecture 3 tiers

Bonjour,

Je commence à développer une application en MVC (mon responsable insiste sur le MVC :)). Au départ ça me semblait adéquat mais je vais devoir ajouter une couche DAL car ma boite planifie de changer de SGBD.
Seulement sur internet je vois pas mal d'avis différents à ce sujet. Certains disent que le MVC est la partie présentation du 3 tiers, je ne comprends pas cette logique. J'ai aussi lu que le DAO est un pattern à part entière. Je pourrais donc l'utiliser seul (sans les autres couches 3 tiers) ? Du coup je suis un peu perdue. Je souhaiterais combiner ces 2 architectures notamment pour garder la partie Contrôleurs du MVC et la partie DAL des 3 tiers.
Merci de votre aide.

Bonjour,
Je ne suis pas certain de comprendre : DAL == DAO ?
Si c'est bien ça, ce tutoriel répondra a toutes vos questions:Tuto

Le MVC tu as la vue qui est la partie présentation.
La DAL c'est la partie métier
et le controleur pour la partie Business
Perso sur un projet on à mis en place la vue avec databinding ensuite le controleur pour lié la couche métier à la couche présentation
La DAL dans la partie métier avec une DTO pour manipuler les données et une BL (POCO) pour les règles sur ces données

Pour la DAL penche toi sur entity framework

Mais le mvc est vraiment un pattern que tu devrais étudier pour vraiment le comprendre.

model vue controleur
La vue c'est la couche présentation
Controleur la liaison entre le model et la vue
Model pour la partie accès au données et gestion de ces dernières

En gros

Si je ne comprend bien le DAO c'est l'ensemble des objets qui représentent les tables de la base de données, ou les entités.

la couche modèle se compose de la manière suivante:

- DAL (Data Access Layer) cette couche met à disposition des méthodes permettant d’ajouter, mettre à jour, lire, supprimer un enregistrement, et ce quelque soit le support de stockage des données (Repository).

- Entités (DAO): comme je disais c'est l'ensemble de tes entités

- ORM (Entity Framework, NHibernate...)

- BAL (Business Acess Layer): couche métier

En espérant t'avoir aidé.

Au dela de la BAL, entity framework va générer tout le reste.

Citation:

---

Envoyé par jouana

La DAL c'est la partie métier
et le controleur pour la partie Business

---

Premièrement métier et business c'est la même chose.
C'est bizarre de mettre tout ce qui est business (enfin je ne sais pas ce que tu veux dire par ce terme) dans les controlleurs, le jour ou tu passes à WPF, silverlight ou autre tu réécris la partie business?

Citation:

---

Envoyé par jouana

Au dela de la BAL, entity framework va générer tout le reste.

---

Tu peux être plus clair?

Enfaite j'ai oublié quelques mots c'est la liaison entre le model et la vue.

Tu as 3 niveau de vérif, coté data (metier avec BL) et coté vue avec le controleur et les validators.

y a une diff entre coller coté métier et les besoin fonctionnelle de l'appli

Après en dehors de la vue toutes nos couches = une dll donc la vue est facilement changeable

Et tu as plein de truc à prendre en compte au niveau du controleur la techno utiliser qui fait que tu peux tout changer.

Je fais du MVC en asp et du MVVM en WPF par exemple
Et le MVVM entre WPF et silverlight (qui est mort) est totalement différent.
Après quand je dit le buissness dans le controleur j'expose le pattern MVC en tps que tel et pas ma manière de l'implémenter.

Perso pour moi la partie buisness est dans la BL qui une couche a part entière

Bonjour Leilou,

Attention à ne pas tout mélanger :)

Premièrement, les deux architectures "ASP.NET WebForms" et "ASP.NET MVC" sont bien différentes.

Bien sur, il est de bonne pratique de créer un découpage logique (et physique éventuellement) 3-tiers en ASP.NET WebForms (Vue - BLL - DAL).

Ceci va donc s'apparenter d'une certaine manière à un découpage "MVC", mais je le redis, intrinséquement, l'architecture de communication entre les classes est bel et bien différente.

Pas mal de monde ont tendance à penser (à tort) que faire du WebForms est moins structuré. Ceci est faux. La différence entre les 2 architectures ne se trouve pas là.

Le MVC quant à lui propose ce découpage de manière plus naturelle de par sa conception, mais au final, il est possible de faire du MVC "sale" en mélangeant le code dans les différentes couches.

Il est très important de connaitre ces différences, pour mieux pouvoir orienter votre décision et votre responsable dans le choix de l'architecture.

Il faut savoir par exemple, que le "coût" de développement ne sera pas le même. En outre, une fois votre architecture choisie et vos développements démarrés, il sera "coûteux" d'en changer.

Il est néanmoins possible de faire cohabiter les 2 architectures, mais cela n'est pas conseillé.

Sur google vous trouverez des articles sur les différences des 2 architectures.

Enfin, votre DAL (que ce soit du MVC ou du WebForms) pourra être effectivement faite avec Entity Framework (mais tout autre ORM peut petre utilisé).

Merci pour vos réponses. Je ne connais pas Entity Framework.
@Poutchyouk : je me suis peut-être emmêlé les pinceaux.
Ce que j'avais compris jusque là c'est que les DAO sont les objets qui font la correspondance entre les objets de mon application (les DTO ou POCO je crois) et les données de mes tables.
Dans mes classes DAO je créais ma connexion à la BDD et toutes les méthodes CRUD. Je pense que je m'y prenais mal car cela est le rôle du DAL non ?
Pouvez-vous me donner un exemple de classe des couches DAO et DAL svp ? Afin de comparer leurs comportements et bien comprendre la différence.
Merci.

Merci Olivier pour ces infos. J'avais lu les articles comparatifs et je pense avoir saisi la différence :) . Mas je trouvais des points intéressants dans les 2 architectures. C'est pour cela que je voulais qqs précisions et conseils pour les combiner au mieux.

Citation:

---

Envoyé par Leilou

Je souhaiterais combiner ces 2 architectures notamment pour garder la partie Contrôleurs du MVC et la partie DAL des 3 tiers.

---

Citation:

---

Envoyé par Leilou

Envoyé par Leilou
Je souhaiterais combiner ces 2 architectures notamment pour garder la partie Contrôleurs du MVC et la partie DAL des 3 tiers.

---

C'est justement cette citation qui me laisse à penser que les choses sont confuses :)

Que vous fassiez du MVC ou du WebForms, vous aurez une couche DAL.
Elle englobera vos objets et Repositories.

Après, DAO, POCO, DTO, ... c'est un autre débat encore.

OK au temps pour moi. Je n'ai rien lu qui allait dans ce sens :?
Je vais un peu mieux me renseigner alors...

La confusion est probablement dans la dénomination des choses.

En MVC, on ne parle effectivement pas des termes BLL et DAL.
Mais au final, on a bien une couche Modèle (qui représente vos objets) à laquelle on va ajouter des repositories pour stocker les méthodes CRUD sur ces objets (+ une classe de context + éventuellement des Repositories génériques...).

Donc, on a bien une DAL, d'une certaine manière.

Pareil pour la couche BLL. On aura tendance à isoler la couche business dans une couche à part afin de ne pas avoir de contrôles métier dans les controller.

Au final vous aurez la cinématique suivante :

Controller <==> Couche Service (équivalent BLL) <==> équivalent DAL.

Les couches sont donc correctement isolées.

Bon après, la frontière entre les choses n'est pas toujours claire... Et les tutoriels qu'on trouve non plus. Premier contre exemple, les tutos Microsoft qui ont tendance à mélanger un peu toutes les couches (contrôles métier dans les controllers, appel des tables dans les controllers, ...)

Citation:

---

Envoyé par Olivier P.

Controller <==> Couche Service (équivalent BLL) <==> équivalent DAL.

---

ça veut dire : Controller échange avec Couche Service (équivalent BLL) échange avec équivalent DAL ?
Parce que pour moi <==> ça veut dire équivaut à.
Je veux pas chipoter, c'est juste pour être sure de bien comprendre :)
Merci.

dans le sens échange (aller-retour) en effet :)

un truc qui me choque :

DAL = data Acces layer : Couche d'accès aux données.

Dans le pattern MVC ce qui s'apparente le plus à la DAL, est la couche Model. Attention toutefois, il me semble que dans une DAL conventionnelle, la couche qui gère la connexion (objet DbConnexion, iDbConnexion, etc), est incluse.

Dans la couche Model (je ne parle que de MVC de chez Microsoft) cette partie est gérée par Entity FrameWork, on a normalement pas à y toucher (attention, info à prendre avec des pincettes).

Et oui, mélanger les pattern n'est pas du tout conseillé.

un tuto en anglais, qui peux surement t'aider à comprendre :

http://www.codeproject.com/Articles/...MVC-Architectu

Pour moi la DAL est un partie du model quand tu eclate le model.
Ensuite tu peux rajouter une DTO, une BL(POCO)

On peut facilement combiner les 2 architectures.

Le MVC est une séparation en couche de l'interface graphique.

Dans notre environement nous avons le MVC (mvvm) pour la partie WPF qui appelle un service découper en architecture n-tier
Coté client (Wpf Application, ClientModel,ServiceAgent)
Coté serveur (service,business logique, idal,dal, dto)

Le model de MVC (mvvm) comprend des objets ClientModel et le controleur fait appel à des méthodes du ServiceAgent.

Tant que vous ne ferez pas la différence entre un pattern d'architecture et un design pattern vous n'allez pas vous en sortir.
Un pattern d'architecture peut utiliser, suivant les couches s'il y en a, plusieurs design patterns. L'inverse est faux et n'a pas de sens.