MVC5 / EF6 Question d'architecture : Les Modèles Code First

Salut,

Dans MVC4 en database first, j'avais pour habitude de créer les entités avec l'EDMX que je mappais sur des objets ayant la même signature mais décorés des attributs Display, Required etc.

Là je travaille sur une application MVC5 EF6 codefirst. Les DataAnnotations sont positionnées sur les membres des classes qui génèrent la base.

Faut-il encore rajouter une couche objet entre la DAL et l'application MVC ou peut-on directement utiliser les éléments de la DAL dans les formulaires ASP.net MVC (sachant qu'en fait la transmission se fait par Web API 2.0 et que la consommation des données est assurée par Angular JS ?

Merchi

Citation:

---

Envoyé par Nadinette

Salut,

Dans MVC4 en database first, j'avais pour habitude de créer les entités avec l'EDMX que je mappais sur des objets ayant la même signature mais décorés des attributs Display, Required etc.

Là je travaille sur une application MVC5 EF6 codefirst. Les DataAnnotations sont positionnées sur les membres des classes qui génèrent la base.

Faut-il encore rajouter une couche objet entre la DAL et l'application MVC ou peut-on directement utiliser les éléments de la DAL dans les formulaires ASP.net MVC (sachant qu'en fait la transmission se fait par Web API 2.0 et que la consommation des données est assurée par Angular JS ?

Merchi

---

Rien ne t'empêche d'ajouter une couche (tu peux le faire directement dans ta bll, qui d'un côté prend des Dto et de l'autre tes entités) et de transmettre plutôt des DTO à ta vue, comme ça tu transmet que ce dont tu as besoin et tu peux créer de nouvelle relation, c'est la solution qu'on avait adopté.
Tu peux aussi travailler directement avec tes entités, mais tu risque de transférer des infos pas pertinentes à la vue et être coincé dans certain cas ou tu veux créer des relations particulières entres tes entités.

Je te conseil donc la première solution avec les DTO, le plus chiant par contre c'est le mapping à toi de voire si tu utilise une bibliothèque pour ça ou tu fais ça à la main.

Bonjour,

Point de vue architecture les couches facades telles que les couches de services Web API , ou la presentation MVC ... doivent etre autonomes (loose coupling) de sorte que ces couches peuvent etres brancheés avec d'autre couche de services ou metiers ou... que pour lesquelles elle sont prevu au depart
Pose toi la question : Si tu change la couche metier est ce que tu dois refaire ton Web APi ou il peut juste s'adapter en moindre effort :
Dans ce sens :

Le MVC donc model view controller : la couche presentation doit avoir des modeles (idem pour les services (facade) ) le modele est autononome et ne doit pas dependre des entities de données que tu sock en base

La demarche est de creer un Modele pour chaque VUE et chaque service et de mapper ensuite celui la a une ou plusieurs entities de base .

Meme si le modele est parfois le meme que l'entity mais il est de bonne pratique de creer un modele decouple de l entity

Citation:

---

Envoyé par youtpout978

Rien ne t'empêche d'ajouter une couche (tu peux le faire directement dans ta bll, qui d'un côté prend des Dto et de l'autre tes entités) et de transmettre plutôt des DTO à ta vue, comme ça tu transmet que ce dont tu as besoin et tu peux créer de nouvelle relation, c'est la solution qu'on avait adopté.
Tu peux aussi travailler directement avec tes entités, mais tu risque de transférer des infos pas pertinentes à la vue et être coincé dans certain cas ou tu veux créer des relations particulières entres tes entités.

Je te conseil donc la première solution avec les DTO, le plus chiant par contre c'est le mapping à toi de voire si tu utilise une bibliothèque pour ça ou tu fais ça à la main.

---

Merci

Pour le mappin, j'utilise EmitMapper qui fonctionne très bien.

Citation:

---

Envoyé par Lakhdr

Bonjour,

Point de vue architecture les couches facades telles que les couches de services Web API , ou la presentation MVC ... doivent etre autonomes (loose coupling) de sorte que ces couches peuvent etres brancheés avec d'autre couche de services ou metiers ou... que pour lesquelles elle sont prevu au depart
Pose toi la question : Si tu change la couche metier est ce que tu dois refaire ton Web APi ou il peut juste s'adapter en moindre effort :
Dans ce sens :

Le MVC donc model view controller : la couche presentation doit avoir des modeles (idem pour les services (facade) ) le modele est autononome et ne doit pas dependre des entities de données que tu sock en base

La demarche est de creer un Modele pour chaque VUE et chaque service et de mapper ensuite celui la a une ou plusieurs entities de base .

Meme si le modele est parfois le meme que l'entity mais il est de bonne pratique de creer un modele decouple de l entity

---

Je vous ce que tu veux dire toutefois, je ne remplis plus mes vues avec des données, elles sont exclusivement alimentées par des webapi (voir des webapi odata) qui s'appuient sur des vues en base. Pour le moment, je ne sais pas encore créer des vues en base en code first mais ça devrait venir. Au pire, je préparerais des scripts que j'injecterai dans le onModelCreating mais j'ai peur que ça ne soit pas très correct d'un pur point de vue de puriste fanatique.

Merci

Oh quand je parle de VUE je parle d'affichage et de non VUE de base de données.
Je parle de VUE(affichage razor,html...) VUE dans MVC .

Dans ton cas tu utilises des services (Web APi,odata ou autres ) ce que j ai essaye de t expliquer c est que point de vue architecture cette couche de service doit etre isolée du reste des couches metiers.
Donc les modeles ou les objets (DTO) que tu envoies a travers ton API doivent etre differents des entités que tu stock en base .

une entite (l objet qu utilise entity framework) peut etre mappe a plusieurs Modeles(DTO)
un Modele DTO peut regrouper plusieurs entites .


Enfin pour les VUEs de base de données c 'est une autre histoire quand tu commencera a regarder pour les performances les agregat ..etc tu verras pour la programmabilite de la base de données.

Surtout que les Vues en BDD peuvent poser problème avec Entity framework.

Emitmapper a l'air assez ancien, tu as aussi Auto Mapper

Quand je veux faire les trucs bien, je crée 3 projets en plus du projet web,l'un contenant mes dto, un autre ma Bll, un dernier ma Dal, après pour les entités c'est suivant ta façon de faire, si c'est du code first je me demande s'il faut pas les mettre dans un projet à part entière.

Tu dois pouvoir trouver des exemples de projet Web Api je pense avec une bonne architecture.

Je te donne un projet que je fais moi meme et tu peux y contribuer si tu veux c est du DDD regarde ici

Du coup, ça m'amène une question.

Lorsque j'ai défini mes entités code first, j'ai mis les data annotations. Ca a bien fonctionné, j'ai vu que les champs avaient les bonnes longueurs et tout.
J'ai aussi mis les display (pour les labels dans les vues mvc).

Si je découple, est-il possible de récupérer les displays et autres règles de gestion qui sont dans les data annotations dans le view model ou pas ?

Merci