Build 2016 : EF Core B852

Tout comme ASP.NET 1.0 Core qui fut renommé à juste escient, EF Core a également été baptisé plusieurs fois avant de posséder ce nom (final ?). Entity Framework Everywhere, Entity Framework 7, et EF Core désignent donc un seul et même framework.

Comme pour la plupart des autres technos de développement Microsof, Entity Framework a évolué avec le temps avec d’être plus agile et livrer de nouvelles versions beaucoup plus rapidement :

image

Tout comme ASP.NET Core, EF Core ne couvre pas le même périmètre fonctionnel qu’EF 6, et est cross-platform :

De la même manière qu’EF cherche à tourner sur différentes plates-formes, Entity Framework cherche à être capable de consommer d’autres types de sources de données.

Les sources de données non relationnelles deviennent en effet de plus en plus présentes, et EF Core va donc s’adapter afin de supporter ces scénarios. Même s’il est à noter que la V1 ne contiendra que les providers relationnels. Des providers pour Azure Table Storage, et Redis devraient être disponibles ultérieurement.

Comme pour ASP.NET Core, EF est basé sur une architecture modulaire et extensible, avec la possibilité de rajouter les briques proposées par Microsoft ou utiliser des briques tierces.

Microsoft positionne EF 6 comme étant la version mature de d’EF, la version stable et fonctionnellement la plus avancée. A noter qu’il est probable que cette version n’évolue plus de manière importante. Vu le discours tenu, on peut penser que Microsoft la considère comme étant feature-complete, et ne fera pas d’investissement significatif dessus.

Quand à EF Core, il s’agit d’un développement from-scratch. Il s’agit donc d’une reélle V1. Il sera possible de porter du code d’EF 6 vers EF 1, mais il s’agira d’une migration avec probablement des adaptations manuelles à faire pour être compatible avec ce nouveau framework.

EF Core

Passons donc enfin à EF Core. Ce nouveau framework abandonne le principe du designer d’EDMX qui permet de manipuler plusieurs fichiers XML pour représenter le modèle. Il sera néammoins bien évidemment possible de gérer les scénarios database-first et code-first. Il n’y aura juste plus de designer usine à gaz, qui manipule des fichiers XML qui ne sont quasiment pas modifiables manuellement.

D’un point de vue performance, Microsoft annonce d’importants gains. Une démonstration est faite sur de la lecture simple d’une table à partir de modèles générées à partir de la BDD :

Les mêmes résultats ont été obtenus avec une requête ayant des critères Where assez simples ainsi qu’un regroupement, mais également sur des requêtes de modifications. Si les gains de performances annoncés sont rééls dans de réélles conditions d’utilisation, il s’agira là d’une très importante amélioration !

L’API de consultation des méta-données a été grandement simplifiée :

La gestion des applications multi-devices et cross-platform est supportée via la gestion de deux scénarios :

  • Partage d’un modèle unique utilisé par des applications sur différentes plates-formes
  • Partage d’un modèle unique stocké sur plusieurs bases de données et synchronisées au sein d’une BDD centrale

Des améliorations au niveau de la génération du code SQL sont également apportées avec notamment le support du batching de mise à jour et d’insertion :

La possibilité de composer une requête mixteà partir d’une requête SQL et d’un requête LINQ :

image

image

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *