Entity Framework et architecture

Bonjour,

Je m'intéresse depuis peu au Entity Framework, dans une architecture MVC, Ntier si possible.

Je ne sais pas trop comment architecturer mon application globalement... donc j'aimerai un retour d'expérience.

Globalement, j'ai déjà 2 projets :

MonApp.Web (application web)
MonApp.Common (objet commun à toute l'application)
MonApp.Model (là sont mes objets métiers qui vont transiter entre les couches)

Ensuite, evidemment :
MonApp.SQLData (qui comprendra mon EDM)

Là, j'aimerai pouvoir ajouter une couche service et les interfaces qui vont avec.

Je me demande si mon MonApp.Model ne sera pas trop en redondance avec les EntityObject généré par l'EDM....

Qu'en pensez vous ?

Il sera forcement redondant, mais la vraie question est de savoir quel interet a pour toi de pouvoir différencier ces classes.

Vu la maniére dont tu veux créer ton architecture, il semblerait qu'il soit important pour toi de pouvoir changer de fournisseur de données.

Salut,

On peut mélanger N-Tiers et MVC?
Quand on fait du MVC avec VS2010 on oublie totalement les couches du N-Tiers. MVC n'est pas une architecture en couches.

A+

Effectivement, je tente de concevoir une application la plus flexible et évolutive possible, car en effet, mes sources de données peuvent être amenées à être changé.

Pour ce qui est du MVC et de l'architecture en couche, je ne vois pas ou est l'incohérence 8O

De plus, je fais du MVC avec du VS 2008 ;)

Alors le prix de la flexibilité et de l'evolutivité est à mon avis dans la redondance de certaines informations. Car tu vas différencier les objets issus de ton model de ceux traités par ta base. Et par conséquent , à tes yeux ils seront différents même si semblables dans le code à un instant donné.

Maintenant si d'autres ont des idées la dessus,n'hésitez pas à intervenir, il y des fois ou je dis des c***** aussi.. :D

Salut,

Tu peux créer un répertoire Objects dans lequel tu rangeras tes couches

Objects
DataLayer
BusinessLayer
CommonLayer
ServiceLayer
PresentationLayer
... PuristeLayer genre : ErrorLayer (qui peut être dans CommonLayer)
... AmoureuxDesCouchesLayer : N'en rajoute pas trop quand même

Bien sûr, si tu utilises Entity Framework, la couche Domain disparait puisqu'elle est encapsulée dans ton modèle.

Si tu travailles avec TeamSystem sur un gros projet à beaucoup de développeurs, mets tes couches dans des DLL séparées et mets un gars sur chacune d'elles et échange les couches entre les gars à chaque itération (pour éviter que la routine s'installe).

Le développement en couches n'a rien à voir avec la technologie d'affichage des pages (qu'elles soient web ou winform).

++

Laurent

Yo,

Citation:

---

Envoyé par Laurent Jordi

échange les couches entre les gars à chaque itération (pour éviter que la routine s'installe).

---

Vous en faite des trucs sympas entre vous :mouarf:

Citation:

---

Envoyé par Laurent Jordi

Le développement en couches n'a rien à voir avec la technologie d'affichage des pages (qu'elles soient web ou winform).

---

Les architectures 3-Tiers sont indépendantes de l'interface.

Une fois encore, il me semble que N-tiers et MVC sont incompatibles tout simplement parce qu'il n'y a pas de couches. Qqn aurait-il un exemple du contraire?

A+

Je dis peut être une bétise, mais MVC ne serait pas un faite un regroupement de plusieurs couche dans la partie Model, View et Controller?

Mmmh c'est ce que j'aurais tendance à penser aussi. Mais peut être comme toi à tort.. :D

Ensuite, je pense que les standards sont aussi faits pour improviser dessus et en faire ce dont bon on semble. Si on veut faire du mvc et le saupoudré de couches à la sauce 3 tiers... pourquoi pas.. :)

(je sens que je vais m'amener les foudres des puristes du design pattern lá.. mais bon! ;))

Citation:

---

Une fois encore, il me semble que N-tiers et MVC sont incompatibles tout simplement parce qu'il n'y a pas de couches. Qqn aurait-il un exemple du contraire?

---

On va relancer le débat la-dessus, mais tu parles de tiers (découpage physique) ou de couches (découpage logique) ?

(et oui, j'ai probablement des exemples pour les deux, mon capitaine ;) )

Bonjour,

Je suis très intéresse par cette question. Je pensais mettre dans un projet les techno Entity Framework que je prévoyais pour la DAL uniquement

et le MVC en guise d'ordonnanceur pour câbler et ordonnancer les appels de service.

Déjà deux remarques :
Les entities ne sont pas de simple poco en ce sens ou ils embarquent des propriétés supplémentaire comme le entityKey (sorte d'identifieur d'objet) et le EntityState permettant de savoir si l'objet est attaché au nom au modèle etc....

J'ai donc disposé des assembleurs a l'intersections de chaque couche.

Concernant la jonction entre ma DAL et mes services je voyais un assembler transformant des poco en entities vice et versa

Concernant la jonction entre mes service et MVC... et bien là je ne sais pas encore.

Ce projet est totalement ludique, il me permet juste d'apprendre a maitriser des techno que les frileux du boulot ne veulent même pas voir. Je suis donc open sur les choix :)

Citation:

---

Envoyé par Immobilis

..Une fois encore, il me semble que N-tiers et MVC sont incompatibles tout simplement parce qu'il n'y a pas de couches. Qqn aurait-il un exemple du contraire?..

---

Je n'ai pas d'exemple, mais je me pose également la question. en allant sur le lien wikipedia que tu as mis il est également dit

Citation:

---

Envoyé par Wikipedia

Dans l'architecture 3-tiers, si une vue modifie les données, toutes les vues concernées par la modification doivent être mises à jour, d'où l'utilité de l'utilisation du MVC au niveau de la couche de présentation. La couche de présentation permet donc d'établir des règles du type "mettre à jour les vues concernant X si Y ou Z sont modifiés". Mais ces règles deviennent rapidement trop nombreuses et ingérables si les relations logiques sont trop élevées. Dans ce cas, un simple rafraîchissement des vues à intervalle régulier permet de surmonter aisément ce problème. Il s'agit d'ailleurs de la solution la plus répandue en architecture 3-tiers, l'utilisation du MVC étant très moderne et encore marginale.

---

Qu'en pensez vous ?

Salut,

EF est une très bonne DataLayer toutefois, dans mes projets, j'encapsule tous les appels à EF dans une couche que j'appelle DataLayer qui est invoquée exclusivement par ma BusinessLayer et qui ne renvoie que des propriétés scalaires ou des objets de ma BuisinessLayer.Facades (qui sont tous sérializable au passage pour bien gérer la persistence temporaire dans le ViewState).

Je ne te conseille pas de l'appuyer directement sur les entités pour alimenter ta couche de présentation car elles présentent beaucoup de limitations par rapport aux objets (par exemple tu ne peux pas faire deux foreach sur la même collection résultante d'une requête EF).

J'ai connu des architectes qui ajoutaient encore plus de couche, c'est vrai que lorsque ça marche c'est génial mais je trouve ça un peu lourd.

A toi de voir donc

++

Laurent

Merci Laurent, ça me conforte dans mon idée.

Je vais utiliser EF uniquement pour la DAL.

Je ne suis pas un adepte de la profusion de couches.

Donc 3 couches me semblent raisonnables

DAL : avec EF
Businness : manipulant les entities fournis par EF et les transformant en poco classique pour la couche présentation
Presentation : ne fonctionnant qu'avec les objets founies par la couche Business.

La seule question que je me pose maintenant, c'est :
Est il judicieux de faire du MVC pour mettre en relation ma Vue (ici la couche présentation) avec mon modèle (ici la couche business)

I'm still working on it.

Citation:

---

Envoyé par Laurent Jordi

Salut,

j'encapsule tous les appels à EF dans une couche que j'appelle DataLayer qui est invoquée exclusivement par ma BusinessLayer et qui ne renvoie que des propriétés scalaires ou des objets de ma BuisinessLayer.Facades [...]

Je ne te conseille pas de l'appuyer directement sur les entités pour alimenter ta couche de présentation car elles présentent beaucoup de limitations par rapport aux objets (par exemple tu ne peux pas faire deux foreach sur la même collection résultante d'une requête EF).

---

Cette description ressemble au pattern MVVM (model-vue / vue model) ;)

Autre détail (corrigez si je me trompe): sous la version actuel d'entity, les entités contiennent également la logique de persistance (sera résolu dans la prochaine version après beaucoup de critiques sur ce point). La facon de procéder de Laurent Jordi permet donc d'empêcher la couche vue de bypasser la couche metier.

Jette aussi un coup d'œil sur Ria services, cela te donnera peut-être des idées.

Merci Julien, je vais voir de ce pas.

Citation:

---

Envoyé par Julien_Dufour

Cette description ressemble au pattern MVVM (model-vue / vue model) ;)

---

Je suis un Jedi, je ne me fie qu'à mon intuition... ;)

++

Laurent

Bahhh aller, quitte à profiter de l'attrait du côté obscur qui permet d'accéder plus vite au pouvoir, je regarderais ce modèle...

Citation:

---

Cette description ressemble au pattern MVVM (model-vue / vue model)

---

Mouais, pas vraiment...

C'est l'utilisation d'un mapper pour convertir un objet donné en DTO pour le transferer aux couches hautes de l'appli

Le MVVM est un pattern de presentation, et a plus ou moins besoin d'avoir des capacités de binding un peu avancées, ce qui fait qu'il est surtout utilisé en WPF/Silverlight...

Citation:

---

C'est l'utilisation d'un mapper pour convertir un objet donné en DTO pour le transferer aux couches hautes de l'appli

---

Ah oui, que moi je prévoyais de faire ça la main les transformations de DTO en entities...

Va falloir que je trouve le juste milieu entre complexité et évolutivité(+ facilité de maintenance)

Jettes un oeil sur automapper, alors ;)