Entity Framework : Quoi de neuf avec EF4 (VS 2010 + Feature CTP1)
Dans la vision de Microsoft, l’Entity Framework est la technologie d’accès à une base de données. Si certains sont déjà convaincus par la V1 (moi par exemple
), il n’en demeure pas moins que pour s’imposer face à N-Hibernate, LLBLGenPro, pour ne citer qu’eux, MS doit continuer d’investir massivement sur cette techno. Bonne nouvelle, c’est exactement ce qui est fait
.
Beaucoup de nouveautés seront donc apportées à la V2 d’EF, également appelée EF4 (pour prendre le numéro de .NET). La plus part ont déjà été annoncées sur le blog EFDesign. Toutes ne sont pas encore disponibles dans la beta 1 dans laquelle on retrouve également des nouveautés sur lesquelles MS n’avait pas communiqué officiellement.
Quelles sont donc les nouveautés de cette Beta :
- le POCO bien sûr. C’est de toute évidence le principal investissement de la part de l’EF Team.
Pour les non initiés, POCO signifie Plain Old CLR Objects. Pour faire simple, il s’agit d’utiliser des entités sans aucune dépendance avec Entity Framework.
Pour activer le lazy loading, il faut renseigner la propriété ContextOptions.DeferredLoadingEnabled à true sur le contexte.
- Les entité “self trackées”
L’idée est de pouvoir déterminer l’état de l’entité quand celle-ci est modifiée indépendamment du contexte. Ceci est notamment très utile dans le cas d’un scénario N-Tiers avec WCF par exemple.
- L’utilisation des template T4 intégrée dans VS 2010.
Le template T4 permet de complètement maîtriser le code généré à partir du modèle. A noter qu’avec VS 2008, il était possible de faire du T4 mais ce n’était pas natif. VS 2010 Beta 1 + EF4 features CTP1 propose 3 templates T4 prédéfinies :
- Le template Prescriptive classes (ie les classes d’entité héritent de classes de l’Entity Framework)
- Le template POCO
- Le template Self Tracking entities
- Les fonctions définies dans le modèle
Vu que je n’en ai encore jamais parlé sur mon blog à ce jour, je vais développer un petit peu.
Imaginons que l’on veuille calculer un âge. Pour cela, il faut faire une différence entre la date courante et la date de naissance. Généralement, c’est la date du serveur qui sert de référence.
Seul problème, comment faire ça avec LINQ To Entities. En effet, si on utilise DateTime.Now, c’est la date du poste exécutant la requête LINQ qui va être prise en compte en non la date du serveur.
Avec EF4, il est possible, dans le CSDL, de définir la function suivante :
<Function Name="GetAge" ReturnType="Int32">
<Parameter Name="person" Type="TestLINQFunctionsModel.Person" />
<DefiningExpression>
DiffYears(person.BirthDay, CurrentDateTime())
</DefiningExpression>
</Function>
Ensuite, cette fonction est utilisable directement dans les requêtes esql.
Ce qui serait vraiment top c’est de rendre cela également possible pour les requêtes LINQ To Entities.
Pour cela, il faut rajouter la méthode à appeler dans la requête LINQ :
public static class PersonExtension
{
[EdmFunction("TestLINQFunctionsModel", "GetAge")]
public static int GetAge(this Person p)
{
throw new NotSupportedException();
}
}
// Bien entendu, rien n’oblige à passer par une extension method.
Il est maintenant possible d’utiliser la méthode GetAge dans une requête LINQ to Entities :
var q = from p in context.Persons
select new { p.LastName, p.FirstName, Age = p.GetAge() };
Cette requête génèrera la requête SQL suivante :
SELECT
1 AS [C1],
[Extent1].[FirstName] AS [FirstName],
DATEDIFF (year, [Extent1].[BirthDay], SysDateTime()) AS [C2]
FROM [dbo].[Persons] AS [Extent1]
Avec un procédé similaire, il est également possible d’utiliser directement des fonctions SQL (TSQL, PLSQL, etc.). Vu que je n’aime pas cette idée car cela casse l’abstraction apportée par EF, je ne développerai volontairement pas ce point.
- La possibilité d’exécuter des requêtes SQL directement
- La possibilité d’utiliser des entités sans modèle
A cela, il faut rajouter plein de nouveautés très utiles dans le designer :
- La gestion des Complex Type
Les complex types sont enfin supportés par le designer même s’ils ne sont visibles que dans le model browser. Il y a même la possibilité de faire du refactoring
- La possibilité de faire du Model First
Il est possible de générer la base à partir des entités.
- La possibilité de “singuliariser” les noms des classes d’entité automatiquement lors de la récupération depuis la base
- La possibilité de supprimer des éléments du SSDL
- La correction des problèmes du style “la propriété est non mappée” pour les complex types et l’Horizontal Entity Splitting
Enfin, il y a plusieurs nouvelle classes et méthodes très pratiques qui ont été rajoutées. Je reviendrai dessus au fur et à mesure de mes posts.
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :