25
AVR
ALT.NET Paris #12 : Entity Framework, compte-rendu par Farid LAOUFI
Posté par farid dans Comptes Rendus Paris | One response so far
Première bougie d’ALT.NET Paris
Tout d’abord, avant de parler du contenu de cette session ALT.NET, je me dois de signaler que notre groupe vient de fêter sa première année, comme l’a indiqué Julien. Donc merci à lui, ainsi qu’à Robert !
Contexte
Entre vingt-cinq et trente personnes étaient présentes à cette rencontre, animée par Mathieu MEZIL. Il a parlé de son sujet de prédilection : Entity Framework. Ce n’est pas pour rien qu’il est MVP sur cette technologie
Si vous souhaitez en savoir plus sur Entity Framework, je vous conseille vivement la lecture de son blog, qui est une vraie mine d’or sur le sujet. En voici l’adresse : http://blogs.developpeur.org/matthieu/default.aspx.
Avant que commence la présentation, chaque participant s’est brièvement présenté et a indiqué les raisons de sa venue. Beaucoup avaient pour objectif de se faire une idée de la technologie; de plus, à peu près tout le monde a déjà utilisé un outil de mapping objet/relationnel « maison » ou un produit tel que NHibernate.
Fondamentaux d’Entity Framework
Après une petite introduction sur ce qu’est Entity Framework, Mathieu nous a montré un schéma de Julia LERMAN résumant assez bien les possibilités de l’outil, puis nous a dit qu’il aimait beaucoup ce dernier… Au cas où quelqu’un n’aurait pas compris le message, il a enlevé son pull pour que tout le monde puisse admirer son beau tee-shirt « I love EDM ». Très émouvant
Plus sérieusement, Mathieu nous a indiqué que des providers Entity Framework pour les principales bases de données devraient être actuellement disponibles, il n’a pu le confirmer avec certitude que pour SQL Server (le contraire eut été surprenant
), Oracle et MySQL. Il nous a également précisé que Microsoft est vraiment en train d’investir à fond sur Entity Framework (environ 150 personnes affectées à ce projet chez Redmond !), et ce dans l’optique de proposer une solution unifiée concernant les problématiques d’accès aux données et de mapping objet/relationnel. Quid de LINQ To SQL ? Eh bien c’est très simple : d’après Mathieu les quelques personnes encore affectées à ce projet ne font qu’écrire des assistants permettant de porter un existant LINQ To SQL vers Entity Framework. Je vous laisse tirer les conclusions qui s’imposent…
Scénarios de mappings
L’un des points forts d’Entity Framework est de permettre une très grande souplesse dans le mapping entre les données présentes en base et les entités définies dans du code .NET. Voici quelques-uns de ces scénarios.
Simple
Similaire à ce qui est propose dans LINQ To SQL : une table est mappée à une entité.
Vertical splitting
Scénario dans lequel une relation 1-1 existe entre deux tables, Entity Framework autorise un mapping de ces deux tables sur une unique entité.
Inheritance
Application des principes de la programmation orientée objet au mapping objet/relationnel (par exemple l’héritage).
Entity Framework, concrètement
Tout d’abord, il faut partir du principe qu’il est possible avec Entity Framework de donner différentes perspectives d’une même donnée présente en base : il est donc envisageable (et recommandé) de créer plusieurs modèles Entity Framework qui sauront mieux s’adapter à certains besoins.
Un modèle Entity Framework est constitué de trois briques distinctes :
- Le SSDL, décrivant tout ou partie de la base de données
- Le CSDL, décrivant les entités
- Le MSL, décrivant le mapping entre les objets de la base de données et les entités
Sans rentrer dans les détails, ces trois parties se modélisent dans un fichier au format XML, ce qui rappelle ce qui se fait pour NHibernate, à une exception près : pour un modèle Entity Framework donné, toutes les informations le décrivant doivent être contenues dans un même fichier XML, ce qui peut s’avérer gênant si deux développeurs ont à le modifier simultanément… Ce point sera corrigé dans la version 2 d’Entity Framework. Ceci étant dit, il y a quand même quelques points positifs à souligner
Les voici :
- L’intégration dans Visual Studio, avec la présence d’un designer, même s’il n’intègre pas certaines fonctionnalités « avancées » d’Entity Framework.
- Encore l’intégration dans Visual Studio, permettant la génération automatique du code C# correspondant
- Dans le code C# généré, les classes représentant les entités sont prêtes pour être utilisées dans des scénarii WCF
- Toujours dans le code C# généré, les classes sont partielles, ce qui permet de les étendre sans risque de perdre ses modifications.
Lorsqu’un modèle Entity Framework a été défini, il est possible de l’utiliser via un objet ObjectContext. Un tel objet a généralement une portée définie via un bloc using dans lequel plusieurs opérations pourront être effectuées sur le modèle, puis finalement sur la base de données, le tout de manière transactionnelle. Un objet ObjectContext gère également un cache qui peut être paramétré finement, assimilable au cache de premier niveau de NHibernate. Un cache de second niveau (utile pour certaines données tels que des listes de pays, … qui n’évoluent quasiment jamais) sera disponible dans la prochaine version d’Entity Framework.
Dans la portée d’un objet ObjectContext, il est bien entendu possible d’effectuer des requêtes. Le plus simple consiste à utiliser LINQ : chaque type d’entité est exposé comme une collection, avec du coup des possibilités de jointures, de filtrages, de tris, … En complément de LINQ, Entity Framework met à disposition une syntaxe pseudo SQL nommée ESQL, permettant de requêter non pas la base de données (tout du moins pas directement), mais plutôt le modèle Entity Framework. A noter qu’il est tout à fait possible de combiner, au sein d’une même requête, les capacités de LINQ et d’ESQL, ce qui laisse envisager des perspectives intéressantes pour traiter nos données.
Mathieu nous a également montré une méthode permettant de combiner Entity Framework avec ADO.NET Data Services.
Un dernier point avant de conclure : les entités peuvent être des POCO avec la version 1 d’Entity Framework, pour cela il faut mettre en œuvre un projet disponible sur MSDN Gallery. L’aspect POCO sera nativement en charge à partir de la prochaine version d’Entity Framework.
Conclusion
Cette présentation fut très intéressante, d’un très bon niveau (maintenant je sais vraiment ce qu’est Entity Framework), et le présentateur maîtrisait parfaitement son sujet (même si on a dû se relayer pour lui apporter des verres d’eau
). Comme d’habitude (c’était ma troisième participation à une rencontre ALT.NET), les questions, remarques et polémiques ont fusé…
Reader's Comments
Laisser un commentaire
-
25 avril 2009, 14:07 -
Comptes Rendus Paris -
Un commentaire
-
Flux RSS des commentaires


Personne n’a foncé sur le sujet de la persistance ignorance ? Un sujet qui me semble assez primordial dans la version actuelle (cf. vote de défiance de la communauté qui a circulé à un moment…) !! D’ailleurs, pour EF4, c’est enfin prévu
(http://blogs.msdn.com/adonet/archive/2009/05/11/sneak-preview-persistence-ignorance-and-poco-in-entity-framework-4-0.aspx)
Sinon, certes je n’étais pas là, mais la phrase « C# généré, les classes représentant les entités sont prêtes pour être utilisées dans des scénarii WCF » me semble aller à l’encontre de la conception de services dans le sens où le contrat de services est directement dépendant de la modélisation métier (avec tout un tas de problématique : héritage même si c’est pris en charge par XSD, sérialisation de propriété en lazy loading, contrat de service stable Vs capacité de refactoring du modèle métier, versionning du contrat de service…). J’ai déjà tenté cela avec NHibernate, c’est sioux…
Je suis plutôt partisant de contrat de service (DataContract en WCF) bien séparé du modèle métier de l’application. Les services sont une façade et ne doivent pas être ultra-dépendant du modèle métier.