Mapping objet relationnel

1. Mapping objet relationnel Mitsuru FURUTA – Microsoft France mitsufu@microsoft.com http://blogs.microsoft.fr/mitsufu

2. Objectifs de la présentation • C’est une présentation technique ! • Appréhender les concepts • Comprendre les problématiques • Etre capable d’évaluer un produit • Mettre en œuvre les principes fondamentaux sous forme de courtes démos • Pas de présentation de produit • Pas de parti pris • Pas de LINQ… • C’est une présentation technique !

3. Mapping objet relationnel • Introduction • Modélisation • Architecture • Fonctionnalités attendues de la couche objet • Productivité • MySolution: DSMap, un DataSet objet… La pause ? Quelle pause ?

4. Introduction • Enjeux et problématiques • Database != objects • Architecture multi-couche: DAL, business, présentation • Est-il possible d’automatiser la DAL ? • Amener la persistance aux objets métiers • Modélisation • Recherche du modèle unique • Requêtage • Tuer le SQL • Implémentations • Outils ou framework ? • Modèle intrusif ou pas • Solutions souvent techniques • Génération de code: templates dynamiques, CodeDom • Abstraction: proxy dynamique, tissage

5. Introduction • Idéal ? • Le pur mapping O/R ne requiert aucun prérequis ni de la part de la base ni de la part de la couche objet. Il assure le lien entre les deux quelques soient les modèles. • La solution assure en général l’accès à la base et la création automatiques des objets (classFactory). • Les solutions sont en général riches mais coûteuses en ressources et en performances. Data base Objects Mapping O/R

6. Introduction • Réalité • De nombreuses solutions ont le parti pris de se baser soit sur la base soit sur les objets. • Les informations de mapping accompagnent alors le modèle choisi et servent à générer le modèle opposée (la base ou les objets) • Ces modèles s’utilisent dans la phase de développement. Ils offrent un meilleur niveau de performance en contre partie d’un certain nombre de restrictions sur le modèle généré Data base Objects Mapping O/R Infos de mapping Infos de mapping

7. Etat de l’art: les générateurs • Database Centric: type Olymars Générateur Développement Exécution Data base Objects Infos de mapping

8. Etat de l’art: les générateurs • Object Centric: type DTM (Evaluant) Générateur Développement Exécution Data base Objects Infos de mapping

9. Que recherchons nous vraiment ? • Automatisation de la DAL • Performance • Consommation mémoire • Productivité • Outil de conception • Abstraction de la base • Gestion du changement ? • Constat • Nous avons tous des attentes différentes • Nous savons que cette couche est déterminante • Beaucoup de solutions et beaucoup de polémiques

10. Sans rien… Demo

11. Modélisation • Base de données • Tables, colonnes, types simples • Clés: primaires, étrangères, composites, indexes • Relations • Héritage • Objets • Classes, champs, propriétés • Compositions (types complexes), portées • Relations • Héritage: relationnel ou non • Modèle physique et conceptuel • Les objets plus proches du modèle conceptuel

12. …avec des objets Demo

13. Architecture • Organisation en couches • DAL: data abstraction layer • Business/Rules: couche métier • Présentation: interface utilisateur (windows/web, autre) • Distribution • Possibilité de distribuer la couche DAL: choix complexe et déterminant • Choix d’un modèle communiquant (MarshalByRef) • Choix d’un modèle externe: sérialisation personnalisée ou génération d’un modèle communiquant • Cette possibilité est souvent ignorée. Il devient pourtant rapidement tentant d’offrir cette couche basse de l’architecture au reste d’un modèle distribué • Il est important de poser cette question au plus tôt car les contraintes sont nombreuses (sérialisation, cache distribué, threadsafe ?, sessions, transactions « mémoire »)

14. Architecture • Modèles d’implémentation • Modèle répétitif • Chaque couche définit ses objets/interfaces: • Avantages: indépendance totale • Inconvénients: gourmand et complexe • Modèle navigant • Les différentes couches d’échangent un unique objet persistant • Avantages: un seul objet à concevoir, pas de duplication mémoire, simple • Inconvénients: dépendance entre les couches (l’abstraction via des interfaces permet au moins de libérer la dépendance binaire) • Enjeux • Concevoir dès la phase de définition d’architecture la nature précise de cette couche • La possibilité de rendre les objets distribuables ainsi que les choix de dépendance (interfaces, portées) sont souvent des contraintes importantes d’une architecture d’implémentation.

15. Organisation en couches Demo

16. Fonctionnalités attendues de la couche objet • Données • Relations/Navigation • Requêtes • Transaction • Cache • Mise en œuvre

17. Fonctionnalités attendues de la couche objet:Données • Gestion de la nullité: data == System.DBNull.Value ? • Object: boxing/unboxing (non typé) • SqlTypes • Nullables: int? • Projection variable • Associer des chargements de colonnes variables dans vers une même classe: « SELECT FIELD1, FIELD2,…, FIELDN FROM… » • Le « SELECT * » n’est pas toujours faisable (données trop grandes, blob), modifier le modèle n’est pas la solution • Versionning de données • Pouvoir jongler avec plusieurs jeux de données d’un même objet: AcceptChanges/RejectChanges

18. Gestion de la nullité Demo

19. Versionning Demo

20. Fonctionnalités attendues de la couche objet:Données • Suivi des modifications • Mettre en œuvre un moyen de tracer toutes les modifications sur les objets persistants: • Notification au niveau des propriétés: pattern « PropertyNameChanged », INotifyPropertyChanged • Notification sur les collections: CRUD (Create, Update, Delete) • Le système est coûteux et non générique même s’il y a un mieux avec INotifyPropertyChanged (.Net 2.0) • Databinding • En WinForms ou WebForms • Le mapping objet relationnel tente d’automatiser la DAL, essayons de ne pas perdre le databinding ! • Respect des interfaces de binding: IList, IBindingList, etc…

21. Suivi des changements Demo

22. Fonctionnalités attendues de la couche objet:Relations/Navigation • Navigation • Chargements en cascade • LazzyLoading • Chargement à la demande lors de la navigation: client.Orders[0].Date • Paramétrage • Collections • Chaînage des appels entre collections et éléments • Intégrité • Profiter des informations relationnelles de mapping pour valider l’intégrité d’un graphe d’objet (de nombreuses notifications sont alors nécessaires)

23. Fonctionnalités attendues de la couche objet:Requêtes • Génération automatiques des requêtes CRUD • Dynamique: à la demande • Statique: lors de la génération (si le modèle le propose) • Problématiques • Performance ? • Procédures stockées, vues ? • Accès total à la vue physique de la base de données: sécurité ? • Sémantique • Avoir un langage unique pour requêter en mémoire parmi les objets ou vers la base de données grâce aux informations de mapping: OQL ? XPath ? Linq ? 

24. Fonctionnalités attendues de la couche objet:Transaction • Possibilité de travailler de manière transactionnelle sur un graphe d’objets persistants • Notion de session nécessaire même dans un environnement non distribué • Isolation des modifications par client (idem base de données) • Implémentation des actions Commit et Rollback sur le graphe • Nouveauté • Profiter du namespace System.Transaction de .Net 2.0 • Exemple de dataset transactionnel: http://www.techheadbrothers.com/DesktopDefault.aspx?tabindex=1&tabid=7&AId=120

25. Fonctionnalités attendues de la couche objet:Cache • Les solutions de mapping O/R imposent par définition le mode déconnecté • Créer ou ne pas recréer un objet déjà chargé ? Avantages et inconvénients • Une ClasseFactory facilite normalement le branchement d’un cache d’objet (unicité de la création) • Définir les données du cache, sa stratégie • Versionning • Exemple de mise en œuvre • A la limite du garbage collector

26. Mise en œuvre d’une solution de cache Demo

27. Fonctionnalités attendues de la couche objet:Mise en œuvre • Mapping • Par attributs • Avantages: lié au code, intégrité • Inconvénients: lié au code • Par fichier externe • Avantages: indépendance du code, possibilité de fournir plusieurs versions • Inconvénients: pas intègre • Ajout de fonctionnalités • Par classe partielle: facile mais non objet • Par héritage: classe de base • AOP: • Dynamique, par interception: MarshalByRef • Par tissage: AOP

28. Interception de méthode: MarshalByRef Demo

29. Premier mapping Demo

30. Productivité • Outils • Externalisation des informations: mapping, méta-données • Générateurs: de schémas de base de données, de classes • Conception visuelle • Extensibilité de Visual Studio • Addins • Wizards • Designers • Project & item templates

31. MySolution: DSMap, un DataSet objet ?!?! • Pourquoi développer sa propre solution: • Appréhender la difficulté ? • Mettre en place une solution originale ? • Etre plus apte à juger les produits existants ? • Conclure qu’il vaut mieux utiliser une solution du marché ? • Coller au mieux à ses besoins ? • Vous faire partager l’expérience • Se coller des cernes la veille d’une présentation technique rue de l’Université ?

32. Solution proposée : objectifs • Avoir une solution indépendante de la source de données • Etre proche de la performance et de la consommation mémoire d’un modèle RAD avec chargement direct dans un DataSet • Conserver les fonctionnalités de « DataBinding » et d’utilisation en mode « design » • Fournir à la couche métier une unique interface d’accès aux données entièrement objet

33. Solution proposée : avantages Solution entièrement .Net car s’appuyant sur les DataSets. Modèle indépendant de la source de données (base, xml, mémoire). Chargement unique des données en mémoire dans un DataSet, le reste des classes persistantes offrant uniquement des accesseurs.

34. Solution proposée : avantages • Création entièrement dynamique des collections et des éléments lors d’un parcours d’un graphe d’objets. • Plusieurs modes de création automatique des objets : systématique, cache. • Avoir des accesseurs non publics, en lecture, écriture ou lecture/écriture

35. Solution proposée : avantages • Charger un nombre de colonnes variable dans un même objet mappé • Support du foreach pour les collections • Support du DataBinding des objets et des collections • Support du binding complexe vers les propriétés et les sous-propriétés d’un objet persistant (DataMember)

36. Solution proposée : avantages • Héritage de classes • Support des collections hétérogènes avec classes héritées • Mises à jours vers la base (Create, Update, Delete) via les fonctionnalités classiques des DataSets (requêtes auto-générées ou personnalisées)

37. Solution proposée : contraintes • Solution entièrement .Net car s’appuyant sur les DataSets • Classes de base imposées pour les collections et les éléments • Chargement des clés primaires et étrangères obligatoires

38. Rappels Demo

39. Infos mapping Commands, DataAdapters Infos mapping RelationalDataAdapter CRUD DataMapping • Infos mapping • par attributs • Par code IDBContext DBContext IDataSetProvider IAutoUpdate Solution proposée : architecture Mauvaise nouvelle IL FAUT CODER !!! Data base Xml DataSet Objects Mémoire SqlDBContext OracleDBContext ADODBContext

40. DataTable DataSet DataClassCollection DataClass Property Solution proposée : architecture DataTable Data source DataTable DataView DataRowView Field (Client) (Client.Nom) (Clients[])

41. dataView[] DataRowView DataClass IList.this[int index] DataRowView DataRowView Réécriture de l’interface IList afin de retourner une instance de DataClass au lieu de DataRowView. class Client : DataRowView row Solution proposée : architecture [DataClass(«ID»)] class ClientCollection : DataClassCollection, IEnumerable, ICollection, IList Client this[int index] { get { return GetItem(index); } } DataClass String Nom { get { return row[«NAME»]; } }

42. Solution proposée :mapping simple Client : DataClass String Nom { get { return (string) row[«NAME»]; } set { row[«NAME»] = value; } }

43. Solution proposée :mapping de relations Client : DataClass [DataClassRelation("customerid", "customerid")] public CommandeCollection Commandes { get { return (CommandeCollection) this.relations["Commandes"]; } } [DataClassRelation(“(customerid=@custumerid) and (state = 1)")] public CommandeCollection CommandesLivrees { get { return (CommandeCollection) this.relations["Commandes"]; } }

44. Solution proposée :mapping de références Commande : DataClass [DataClassReference("customerid", "customerid")] public Client Client { get { return (Client) this.references["Client"]; } }

45. DSMap Demo

46. Questions/Réponses

47. © 2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.