Architecturer un projet MVC en N-tiers, avec entity framework

Bonjour à tous,

Afin de me former à entity framework, j'ai suivi le tutoriel "Contoso University" de Microsoft.

Ce tutoriel permet de réaliser un site web en MVC avec entity framework et en utilisant les pattern repository et unit of work.
A la fin de celui-ci, on se retrouve donc avec la solution suivante sous visual studio :

http://www.developpez.net/forums/att...4&d=1382609945


J'aimerai maintenant modifier mon projet pour le séparer en couche :
- présentation
- logique métier
- accès à la base de données

Mais je bloque pas mal sur ce point :aie:

Dans un premier temps, j'ai crée deux nouveaux projets :
- BLL, dans lequel j'ai déplacé le répertoire "Models" et "ViewModels" de ma solution initiale
- DAL, dans lequel j'ai déplace le répertoire "DAL" de ma solution initiale

Mais ce faisant, pour que mon projet DAL fonctionne, je dois lui rajouter une référence vers le projet BLL (le fichier SchoolContext a besoin de connaitre les objets définis dans le Model, de même pour l'implémentation du pattern uow, etc...).
Et avec cette configuration, j'ai l'impression d'être à côté de la plaque. En effet, mes controllers vont appeler un objet "unit of work", mais celui ci est dans la couche DAL et dépend de la couche BLL :aie:

De façon plus globale, comment passer d'un modèle en MVC, en un modèle MVC N-tiers, lorsque l'on utilise entity framework (code-first) ?
J'ai parcouru de nombreux exemples sur le net, mais à chaque fois il y'a pleins d’éléments en plus qui complexifie et je ne m'y retrouve plus. C'est pour ça que je voulais repartir d'un exemple que j'ai à priori compris.

Merci d'avance :ccool:

Bonjour,

La première chose à faire est de penser au besoin de chaque couche en partant de la DB jusqu'à l'application.

Citation:

---

Que doit faire la DAL? Que doit-elle retourner?

La DAL va te permettre de renvoyer des objets qui ont pratiquement le même schéma que les tables de la base de données.

Donc ton "Model" doit se retrouver obligatoirement à ce niveau. Pour ma part en utilisant l'approche Code First, cela me pose pas de problème de renvoyer directement les "entités". Par contre à l'utilisation de "Model First" ou "Database First", il est conseillé de ne pas renvoyer les entités mais des DTO (ou POCO).

Personnellement, j'utiliserais le principe du "Repository Pattern" à cet endroit.

Autour du BLL avec les mêmes questions. Que doit-il faire et retourner?

Pour sa part, le BLL va traiter les informations provenant de la DAL et de l'UI. Faire des vérifications, des traitements "logique" et pour ma part je rajouterais des transformations.

Dans ce cas, je choisis donc de mettre mes "ViewModel" dans ce projet et le BLL va donc transformer les Models en ViewModel.

---

Dans ce cas les principes de base sont respectés.

DAL: N'a besoin de rien.
BLL: Connait que DAL
UI: Connait que BLL

Sur ce, bonne journée et courage. ;)

Déjà merci de ta réponse.

Pour être sur d'avoir bien compris, dans ton cas de figure tu doit donc avoir :
- un viewModel par Model,
- les entités d'entityFramework font office de de Model.

Par contre, un truc que je ne comprends pas bien, dans tes controllers comment fais tu les appels aux fonctions de persistances ? Met tu les appels aux repository dans les viewModels ?

Citation:

---

Envoyé par Arnaud13

Pour être sur d'avoir bien compris, dans ton cas de figure tu doit donc avoir :
- un viewModel par Model,

---

Non, tu aurais plutôt un ViewModel par View. Mais ce concept est plutôt lié directement à la partie MVC.

Citation:

---

Envoyé par Arnaud13

- les entités d'entityFramework font office de de Model.

---

Dans ce cas-ci oui.

Citation:

---

Envoyé par Arnaud13

Par contre, un truc que je ne comprends pas bien, dans tes controllers comment fais tu les appels aux fonctions de persistances ? Met tu les appels aux repository dans les viewModels ?

---

Un petit Exemple :

Code:

---

1 2 3 4 5 6 7

MVC: Controller | | BLL : List<UserViewModel> GetAllUsers(); | | DAL : List<User> GetAllUsers();

---

Donc c'est l'exemple le plus simple ici, et le GetAllUsers de la BLL va juste convertir les "User" en "UserViewModel".

Citation:

---

Envoyé par SoBaKa

Non, tu aurais plutôt un ViewModel par View. Mais ce concept est plutôt lié directement à la partie MVC.

---

Effectivement, erreur de langage dans mes propos :aie:

Citation:

---

Envoyé par SoBaKa

Donc c'est l'exemple le plus simple ici, et le GetAllUsers de la BLL va juste convertir les "User" en "UserViewModel".

---

Je crois que c'est le point qui me manquait. Je voulais que mes entités correspondent à mes Models, mais en fait, il faudrait que je crée pour chaque entités une classe dans ma BLL qui utilise le repository qui va bien ? D'ailleurs quel nom donne t on à ces classes ?

Après, soit j'utilise directement les entités dans ces classes de ma BLL, soit je convertis mes entités en DTO. C'est bien cela ?

En discutant un peu avec un collègue et avec les infos de ce message je pense faire de la façon suivante :

- utilisant de viewModel pour la partie UI
- utilisant de classe Domain pour la partie BLL
- utilisant des entités d'entity framework pour la partie DAL

pour une entité simple, je vais copier les mêmes propriétés dans la classe Domain et dans la viewModel et utiliser des DTO pour passer les informations d'une couche à l'autre.
C'est redondant aux niveaux des classes de chaque couche, mais comme ça j'ai une bonne séparation.

Je laisse ce message ouvert quelques temps, voir s'il y'a des retours sur la solution que j'envisage et je le passerai en résolu.

Merci SoBaKa :ccool:

Le coté redondant est un "code smell", ça veut dire que la maintenance sera plus difficile car tu devras modifier le code à plusieurs endroits !

En fait l'approche que tu décrit est utile dans le cas où ta couche UI et ta couche BLL/DAL sont sur des machines différentes, dans ce cas tu ne peux pas faire voyager tes entités sur le réseau, car le plus souvent (ça dépend de l'ORM utilisé, mais c'est le cas par exemple pour Nhibernate) elles sont liés à une connexion BD donc à la machine où elles ont été créés.
Donc, tu dois passer par un objet intermédiaire (le DTO ou Data Transfert Object) qui lui peut voyager sur le réseau, c'est d'ailleurs sa seule raison d'être.

Mais, ici ce n'est pas le cas, donc dupliquer les données entre objet du "Domaine" et objet "Entité" est inutile, en fait, c'est justement pour éviter cela que l'on demande aux ORM de pouvoir gérer des POCO (des Plain Old C# object ou "bon vieux objets C#"), ainsi tes entités et ton modèle du domaine sont une seule et même chose.

Ton modèle du domaine/entité est constitué d'objet dit "anémique", c'est à dire qu'il n'ont pas de méthodes, justes des données. Le comportement associé à ces données, est dans des services qui constituent ta couche BLL (Business Layer, c'est la logique du domaine).

Enfin, le remplissage des view model à partir des entités, est fait par ton contrôleur, pas par tes services car ce n'est que de la présentation. En fait, tu as même une variante qui se contente d'utiliser les entités comme view model.