[Teched 2007] Entity Framework Introduction
Carl Perry - Senior Program Manager Lead, Microsoft
Une session devant être normalement riche en nouveautés de mon coté car, au moment ou je pénètre dans la salle de conférence, je n'ai vraiment aucune idée de ce qu'est l'Entity Framework.
Rappels sur l'accès aux données avec ADO.NET 2.0: Création de connexion à une base de données, définition d'une commande en SQL (par exemple sur une jointure de deux tables) et exécution de celle-ci au travers d'un reader pour extraire les données jointes: modèle de manipulation et d'extraction de données extrêmement performant mais nécessitant de connaitre la base de données.
Positionnement de ADO.NET Entity Framework: manipulation d'objets (au sens .NET) plutôt que d'objets SQL.
ADO.NET 2.0 vs ADO.NET Entity Framework:
• Abstraction: Bas niveau sur schéma de la base vs schéma conceptuel plus haut niveau
• Langage de requêtage: requête entre "" vs LINQ
• Résultat de requête: Faiblement typé contre fortement typé
Vocabulaire:
• Entity Data Model (EDM): terme utilisé pour définir la description un schéma conceptuel. Modélise graphiquement les données que l'application veut voir (et non pas peut voir).
• Entities: Types distinct, simple ou complexes
• Relations: Mise en évidence des relations entre les types via une déclaration explicite.
L'entity Framework se positionne donc non par a coté, mais par dessus les providers d'accès aux données d'ADO.NET. Source de données => ADO.NET 2.0 Data Providers => EntityClientDataProvider (pour extraire les données) => Entity Framework Object Services (pour exposer les données sous forme d'object utilisables dans le code).
Première démonstration: utilisation de l'Entity Framework:
- Création d'une application ASP.NET
- Ajout d'un fichier de type "ADO.NET Entity Data Model" au projet
- Sélection d'une base de données cible
- Sélection des tables, vues et procédures stockées devant apparaitre dans le modèle
- Représentation, dans une sorte de "Class Diagram", des éléments (tables et vues) et des relations. Chaque entité contient des propriétés (mappées sur la structure de la table cible) et des éléments de navigation permettant par programmation de naviguer de relation en relation. Le diagramme est généré à partir du schéma de la base de données, mais celui-ci peut ne pas correspondre à la réalité, il est donc possible ensuite de redéfinir le modèle, les relations et le mapping, en ajoutant par exemple dans une entité des données issue d'une relation avec une autre table => ADO.NET Entity Data Model se charge automatiquement de générer la requête permettant de peupler l'entité.
Comment manipuler un Entity Data Model? Deux approches: LINQ ou Entity SQL (syntaxe SQL classique)
- LINQ to Entities: Manipulation des entités via LINQ, utile pour la validation de la syntaxe et intelissence
- Entity SQL : ajout de sémantique EDM au SQL, utile pour la création de requêtes dynamiques et la manipulation de procédures stockées. Les requêtes s'écrivent donc en SQL mais en interrogeant le modèle contenant les entités plutôt que directement la base.
Dans les deux cas, toutes les requêtes finissent vers la base sous la forme de requêtes SQL auto-générées.
Deuxième démonstration:
- Utilisation de LINQ to Entities pour paginer des données à afficher dans une GridView ASP.NET 2.0 (utilisation de LINQ classique)
- Utilisation de eSQL pour récupérer une liste d'utilisateurs filtrée: Object<Customer> query = aw.CreateQuery<Customer>("@SELECT VALUE c FROM .... WHERE ...."); avec la possibilité de paramètrera cette requête.
Mon point de vue final: une approche beaucoup plus intéressante et beaucoup plus flexible à l'abstraction de données que les actuels "TableDataAdapter" tout en bénéficiant de la puissance de LINQ pour une manipulation plus fine et plus performante. Une belle couche intermédiaire d'un point de vue conception entre LINQ et les sources de données SQL.
Pour aller plus loin: http://msdn2.microsoft.com/en-us/library/aa697427(vs.80).aspx
