Entity Framework et architecture

Version imprimable

16/09/2009, 15h38
kendras

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 ?
16/09/2009, 17h43
Arthis

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.
16/09/2009, 21h27
Immobilis

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+
17/09/2009, 12h04
kendras

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 ;)
17/09/2009, 12h08
Arthis

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
17/09/2009, 12h13
CUCARACHA

Crée un répertoire à part (ou une DLL)

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
17/09/2009, 19h06
Immobilis

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+
17/09/2009, 21h47
Leelith

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?
18/09/2009, 09h27
Arthis

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! ;))
18/09/2009, 11h54
Philippe Vialatte

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 ;) )
21/10/2009, 11h09
revilo

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 :)
21/10/2009, 11h19
revilo

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 ?
21/10/2009, 11h25
CUCARACHA

Entity Framework est (à mon sens) une DAL Parfaite mais..

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
21/10/2009, 11h43
revilo

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.
21/10/2009, 11h46
Julien_Dufour

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.
21/10/2009, 12h10
revilo

Merci Julien, je vais voir de ce pas.
21/10/2009, 12h38
CUCARACHA

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...
21/10/2009, 13h53
Philippe Vialatte

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...
21/10/2009, 14h00
revilo

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)
21/10/2009, 14h03
Philippe Vialatte

Jettes un oeil sur automapper, alors ;)
21/10/2009, 15h32
Julien_Dufour

Citation:

Envoyé par Philippe Vialatte

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

La "couche DTO" est-elle entre DAL et business ou entre business et présentation?

Edit: Le MVVM etant entre business et presentation, la reponse serait donc : entre DAL et business. Mais dans ce cas, c'est pas dommage de creer des objet a partir d'un ORM, pour les retransformer avant d'envoyer les infos a la couche business? N'est ce pas du ressort de la DAL (ORM dans le cas d'EF) que de donner des objets cleans?
21/10/2009, 15h38
CUCARACHA

C'est quoi l'adresse de l'AutoMapper, je suis assez intéresse là... :)
21/10/2009, 16h35
revilo

Citation:

Envoyé par Julien_Dufour

La "couche DTO" est-elle entre DAL et business ou entre business et présentation?

Entre la Dal et la business.
Enfin j'en fais pas vraiment une couche. plus un Helper qui transforme des Entities issues de EF en objets manipulable par la couche business et affichables.

Note : je pourrais découpler d'aventage en positionnant des DTO entre le business et la couche présentation. Mais dans mon cas ca serait "prendre le bazooka pour tuer la mouche" comme on dit !

:)
21/10/2009, 16h41
Philippe Vialatte

Citation:

C'est quoi l'adresse de l'AutoMapper, je suis assez intéresse là...

http://lmgtfy.com/?q=automapper ;)

Bon, allez, comme c'est pas le genre de la maison, le mieux, c'est de commencer par un webcast

http://dimecasts.net/Casts/CastDetails/111

Et pour plus d'infos, de jeter un oeil sur le blog de Jimmy Bogard

http://www.lostechies.com/blogs/jimm...x?q=automapper
21/10/2009, 16h51
Julien_Dufour

Citation:

Envoyé par revilo

Entre la Dal et la business.
Enfin j'en fais pas vraiment une couche. plus un Helper qui transforme des Entities issues de EF en objets manipulable par la couche business et affichables.

Donc si on a des beaux objets POCO avec la prochaine version d'entity (comme promis), cette partie disparaitra si je te comprends bien :D

Citation:

Envoyé par revilo

Note : je pourrais découpler d'aventage en positionnant des DTO entre le business et la couche présentation. Mais dans mon cas ca serait "prendre le bazooka pour tuer la mouche" comme on dit !

:)

Bon, je pense que le MVVM est se rapproche de ton bazooka :)
(histoire de binding avance mis a part)
21/10/2009, 16h54
CUCARACHA

Tiens au passage, j'ai pas super étudié les helpers... c'est un peu des bretelles pour un mec qui a déjà une ceinture (je fais une analogie avec un cerveau en fait)..
++

Laurent
21/10/2009, 17h10
revilo

@Julien : Oui et oui aussi pour le bazooka :)

@Laurent : N'en déplaise aux puristes, ce que j'appelle ici Helper n'en est probablement pas un.

Il s'agit, dans l'utilisation que j'en ai, de classes static la plus part du temps, proposant des outils divers, ici, conversions d'objets en autre objets.
Je suis donc super mal placé pour parler de Helper, car je connais peu le sujet.

En ce sens Automapper m'intéresse, j'ai regardé rapidement le joli podcast et il part d'un principe que je vais avoir du mal a faire passer:

Je m'explique, il semble utiliser des interfaces de POCO. Cette utilisation est possible car nous avons dans nos classes des accesseurs (get et set), qui sont des méthodes particulières en fin de compte.
Le fait de mettre un contrat sur ces méthodes est donc techniquement possible.

Ce qui me fait réagir, c'est qu'en ce moment je suis sur un projet ou le responsable ne veut pas entendre parler d'interface de POCO. Car c'est pas vraiment objet selon lui...

Pour avoir travaillé sur un projet en java ou l'architecte travaillait en mettant des contrats sur les objets échangés, je dois avouer que je ne sais pas vraiment quoi penser...
21/10/2009, 17h27
Philippe Vialatte

Citation:

Envoyé par revilo

Ce qui me fait réagir, c'est qu'en ce moment je suis sur un projet ou le responsable ne veut pas entendre parler d'interface de POCO. Car c'est pas vraiment objet selon lui...

Ah...bon ???

Je ne sais pas ou il a vu ca...
21/10/2009, 17h36
Julien_Dufour

Citation:

Envoyé par revilo

Pour avoir travaillé sur un projet en java ou l'architecte travaillait en mettant des contrats sur les objets échangés, je dois avouer que je ne sais pas vraiment quoi penser...

C'est exactement la question que je me pose: POCO ou économie de code? (dans le cas d'entity)

Pour l'histoire du POCO qui serait pas un objet, j'avoue ne pas saisir non-plus...:?
21/10/2009, 17h44
CUCARACHA

Ca ne vaut plus le coup d'économiser le code... La j'ai huit coeurs, 6Go de Ram, je peux jouer en 1600x1200 à Age of Conan en detail High avec 2 VM qui tournent dans le bouzin... Si tu fais ramer ce genre de machine, il faut penser à tenter la star'ac...

++

Laurent
21/10/2009, 18h03
Julien_Dufour

Citation:

Envoyé par Laurent Jordi

Ca ne vaut plus le coup d'économiser le code... La j'ai huit coeurs, 6Go de Ram, je peux jouer en 1600x1200 à Age of Conan en detail High avec 2 VM qui tournent dans le bouzin... Si tu fais ramer ce genre de machine, il faut penser à tenter la star'ac...

Par économie de code, je parlais du temps de dev ;)
21/10/2009, 18h06
CUCARACHA

Ben le temps de dev augmente légèrement mais le temps de test et de débogage baisse considérablement, en conséquence, à l'échelle du projet, c'est plus rapide, il faut juste trouver des codeurs mutants avec 6 doigts à chaque main...

++

Laurent
12/11/2009, 11h18
anthyme

Perso je suis contre ce qui a été dit plus haut ...

Avoir 2 domaines objets est une mauvaise idée. EF à été créé pour définir un domaine objet global et unique avec des fonction de mapping avancés permetant de faire abstraction de la structure de stockage de données. Ce n'est pas du tout conçu pour ré encapsuler les données dans d'autres objets...

Après si le coté non POCO d'EF t'embêtes (ce que je peux concevoir) je te conseil vivement d'utiliser NHibernate qui est POCO très puissant et plus fonctionnel qu'EF (et on peut également faire du Linq).

Perso c'est sur une solution NHibernate + Asp.net MVC sur laquel je travail actuellement
14/11/2009, 17h35
Immobilis

3 pièce(s) jointe(s)

Citation:

Envoyé par Philippe Vialatte

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 ;) )

Logique. Le découpage physique est souhaitable pour ne pas s'emmeler les pinceaux. Fondamentalement il n'est pas obligatoire.

Citation:

Envoyé par Laurent Jordi

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).

Tu recréés des objets de transfert? Les objets créés par EF sont parfaitement serializables.
Tu ajoutes tes entités au viewstate?

Citation:

Envoyé par Laurent Jordi

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).

Si, ça marche (en tous les cas avec VS2010 FW4).

http://www.developpez.net/forums/att...1&d=1258225686

Citation:

Envoyé par revilo

Entre la Dal et la business.
Enfin j'en fais pas vraiment une couche. plus un Helper qui transforme des Entities issues de EF en objets manipulable par la couche business et affichables.

Note : je pourrais découpler d'aventage en positionnant des DTO entre le business et la couche présentation. Mais dans mon cas ca serait "prendre le bazooka pour tuer la mouche" comme on dit !

:)

Ca ne vous donne pas l'impression de faire plusieurs fois le même boulot?

Dans une architecture 3 tiers les DTO sont totalement indépendants des couches car ils sont justement commun. Il sont totalement transversaux.

http://www.developpez.net/forums/att...5&d=1258216373
Avec EF c'est la DAL qui créé les entités. Ajouter une couche pour "masquer" ça me semblerait inutile voir non constructif. Si tu choisis d'accéder aux données avec EF ta DAL sera référencée dans ton IHM. Du coup tu t'éloigne du modèle 3 tiers dit en couches. Le Modèle c'est DAL + DTO, le Controleur c'est la BLL, la vue l'IHM.

http://www.developpez.net/forums/att...1&d=1258226355

A+
15/11/2009, 09h10
CUCARACHA

Salut,

Tu as raison sur toute la ligne toutefois si demain mon client souhaite virer entity framework au profit d'un autre système, il ne perd pas toute sa couche data et sa couche Business demeurera intacte (en l'occurrence elle est très complexe).

Je note que tu précises toi même que le coup des boucles fonctionnes sur FW4 alors que nous sommes sur le FW2 avec C# 3.5. Hors de question de livrer en prod une appli développée sur la base d'un FW en beta.

Bien que cette fois-ci je sois assez convaincu par l'outil, je sais qu'il sera éphémère comme tout ce que Microsoft propose. Non pas qu'il va disparaitre mais être remplacé par une version plus puissante ce qui entrainera forcément du recodage.

Lorsqu'on développe, il ne faut pas uniquement penser aux performances et aux règles de l'art. Il faut être pragmatique et intégrer les enjeux et les retombées économiques dans son raisonnement.

Donc, les conseils que je donne n'engagent que moi, tes constats sont certes fondés mais je ne suis pas certain qu'ils intègrent toutes les contraintes liées à l'environnement technico commercial.

++

Laurent

Citation:

Envoyé par Laurent Jordi

Tu as raison sur toute la ligne toutefois si demain mon client souhaite virer entity framework au profit d'un autre système, il ne perd pas toute sa couche data et sa couche Business demeurera intacte (en l'occurrence elle est très complexe).

C'est le principe du découplage. C'est un peu aussi ce que j'ai dit quand j'ai fait mon architecture 3-tiers avec un objet de connexion utilisant les "DbProviderFactories". Maintenant d'un point de vue pragmatique justement, qu'elle est la probabilité de changer de SGBD (nous sommes sous SQL Server)? Chez nous elle est quasie nulle parce que au moment où elle est là elle marche. C'est moins couteux de repartir de 0 que de modifier. A mon avis cela est du au fait que la nouvelle techno qu'on souhaite utiliser pour en remplacer une autre est beaucoup plus efficace si on utilise les nouvelles méthodes de développement associées avec.

Mais cela n'engage que moi.

Citation:

Envoyé par Laurent Jordi

Je note que tu précises toi même que le coup des boucles fonctionnes sur FW4 alors que nous sommes sur le FW2 avec C# 3.5. Hors de question de livrer en prod une appli développée sur la base d'un FW en beta.

J'ai du mal à croire qu'on ne puisse pas faire deux boucles successives sur un "IQueryable" sous VS2008 et FW 3.5. Dslé, j'ai pas VS2008 sous le coude mais je vais essayer avec VS2010 et FW3.5.
==> VS2010 et FW3.5
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Data.Objects; namespace ConsoleApplication1 { class Program { static void Main(string[] args) { using (ECommEntities entities = new ECommEntities()) { ObjectQuery<ANNOUNCE> qr = new ObjectQuery<ANNOUNCE>("ANNOUNCE", entities); foreach (ANNOUNCE item in qr) { Console.WriteLine("ANNOUCE {0}", item.ANN_TEXT); } foreach (ANNOUNCE item in qr) { Console.WriteLine("ANNOUCE {0}", item.ANN_STARTDATE); } } Console.ReadLine(); } } }
A+

15/11/2009, 15h22
CUCARACHA

Je ne parlais pas de changer de SGBD mais de connecteur relationnel objet.

Citation:

Envoyé par Laurent Jordi

Je ne parlais pas de changer de SGBD mais de connecteur relationnel objet.

Pareil, changer une couche quoi...
Sinon, avec LINQ la var est un objet "ObjectQuery" ça marche aussi:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            using (ECommEntities entities = new ECommEntities())
            {
                var toto = from c in entities.ANNOUNCE where c.ANN_ID < 4 select c;
 
                foreach (ANNOUNCE item in toto)
                {
                    Console.WriteLine("ANNOUCE {0}", item.ANN_TEXT);
                }
 
                foreach (ANNOUNCE item in toto)
                {
                    Console.WriteLine("ANNOUCE {0}", item.ANN_STARTDATE);
                }
            }
            Console.ReadLine();
        }
    }
}