Mapping objet relationnel<br />Mitsuru FURUTA – Microsoft France<br />mitsufu@microsoft.com<br />http://blogs.microsoft.fr...
Objectifs de la présentation<br />C’est une présentation technique !<br />Appréhender les concepts<br />Comprendre les pro...
Mapping objet relationnel<br />Introduction<br />Modélisation<br />Architecture<br />Fonctionnalités attendues de la couch...
Introduction<br />Enjeux et problématiques<br />Database != objects<br />Architecture multi-couche: DAL, business, présent...
Introduction<br />Idéal ?<br />Le pur mapping O/R ne requiert aucun prérequis ni de la part de la base ni de la part de la...
Introduction<br />Réalité<br />De nombreuses solutions ont le parti pris de se baser soit sur la base soit sur les objets....
Etat de l’art: les générateurs<br />Database Centric: type Olymars<br />Générateur<br />Développement<br />Exécution<br />...
Etat de l’art: les générateurs<br />Object Centric: type DTM (Evaluant)<br />Générateur<br />Développement<br />Exécution<...
Que recherchons nous vraiment ?<br />Automatisation de la DAL<br />Performance<br />Consommation mémoire<br />Productivité...
Nous savons que cette couche est déterminante
Beaucoup de solutions et beaucoup de polémiques</li></li></ul><li>Demo<br />Sans rien…<br />
Modélisation<br />Base de données<br />Tables, colonnes, types simples<br />Clés: primaires, étrangères, composites, index...
Demo<br />…avec des objets<br />
Architecture<br />Organisation en couches<br />DAL: data abstraction layer<br />Business/Rules: couche métier<br />Présent...
Architecture<br />Modèles d’implémentation<br />Modèle répétitif<br />Chaque couche définit ses objets/interfaces:<br />Av...
Demo<br />Organisation en couches<br />
Fonctionnalités attendues de la couche objet<br />Données<br />Relations/Navigation<br />Requêtes<br />Transaction<br />Ca...
Fonctionnalités attendues de la couche objet:Données<br />Gestion de la nullité: data == System.DBNull.Value ?<br />Object...
Demo<br />Gestion de la nullité<br />
Demo<br />Versionning<br />
Fonctionnalités attendues de la couche objet:Données<br />Suivi des modifications<br />Mettre en œuvre un moyen de tracer ...
Demo<br />Suivi des changements<br />
Fonctionnalités attendues de la couche objet:Relations/Navigation<br />Navigation<br />Chargements en cascade<br />LazzyLo...
Fonctionnalités attendues de la couche objet:Requêtes<br />Génération automatiques des requêtes CRUD<br />Dynamique: à la ...
Fonctionnalités attendues de la couche objet:Transaction<br />Possibilité de travailler de manière transactionnelle sur un...
Fonctionnalités attendues de la couche objet:Cache<br />Les solutions de mapping O/R imposent par définition le mode décon...
Demo<br />Mise en œuvre d’une solution de cache<br />
Fonctionnalités attendues de la couche objet:Mise en œuvre<br />Mapping<br />Par attributs<br />Avantages: lié au code, in...
Demo<br />Interception de méthode: MarshalByRef<br />
Demo<br />Premier mapping<br />
Productivité<br />Outils<br />Externalisation des informations: mapping, méta-données<br />Générateurs: de schémas de base...
MySolution: DSMap, un DataSet objet ?!?!<br />Pourquoi développer sa propre solution:<br />Appréhender la difficulté ?<br ...
Solution proposée : objectifs<br />Avoir une solution indépendante de la source de données<br />Etre proche de la performa...
Solution proposée : avantages<br />Solution entièrement .Net car s’appuyant sur les DataSets.<br />Modèle indépendant de l...
Solution proposée : avantages<br />Création entièrement dynamique des collections et des éléments lors d’un parcours d’un ...
Solution proposée : avantages<br />Charger un nombre de colonnes variable dans un même objet mappé<br />Support du foreach...
Solution proposée : avantages<br /><ul><li>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ée...
Demo<br />Rappels<br />
Solution proposée : architecture<br />Infos mapping<br />Commands,<br /> DataAdapters<br />Infos mapping<br />RelationalDa...
Par code</li></ul>IDBContext<br />DBContext<br />IDataSetProvider<br />IAutoUpdate<br />Mauvaise nouvelle<br />IL FAUT COD...
DataTable<br />DataSet<br />Solution proposée : architecture<br />DataClassCollection<br />DataClass<br />Property<br />Da...
Solution proposée : architecture<br />dataView[]<br />DataRowView<br />DataClass IList.this[int index]<br />DataRowView<br...
Solution proposée :mapping simple<br />Client : DataClass<br />String Nom<br />{<br />  get <br />  {<br />    return (str...
Solution proposée :mapping de relations<br />Client : DataClass<br />[DataClassRelation("customerid", "customerid")]<br />...
Solution proposée :mapping de références<br />Commande : DataClass<br />[DataClassReference("customerid", "customerid")]<b...
Prochain SlideShare
Chargement dans…5
×

Mappingobjetrelationnel[1]

640 vues

Publié le

Publié dans : Formation
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
640
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
13
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Mappingobjetrelationnel[1]

  1. 1. Mapping objet relationnel<br />Mitsuru FURUTA – Microsoft France<br />mitsufu@microsoft.com<br />http://blogs.microsoft.fr/mitsufu<br />
  2. 2. Objectifs de la présentation<br />C’est une présentation technique !<br />Appréhender les concepts<br />Comprendre les problématiques<br />Etre capable d’évaluer un produit<br />Mettre en œuvre les principes fondamentaux sous forme de courtes démos<br />Pas de présentation de produit<br />Pas de parti pris<br />Pas de LINQ…<br />C’est une présentation technique !<br />
  3. 3. Mapping objet relationnel<br />Introduction<br />Modélisation<br />Architecture<br />Fonctionnalités attendues de la couche objet<br />Productivité<br />MySolution: DSMap, un DataSet objet…<br />La pause ? Quelle pause ?<br />
  4. 4. Introduction<br />Enjeux et problématiques<br />Database != objects<br />Architecture multi-couche: DAL, business, présentation<br />Est-il possible d’automatiser la DAL ?<br />Amener la persistance aux objets métiers<br />Modélisation<br />Recherche du modèle unique<br />Requêtage<br />Tuer le SQL<br />Implémentations<br />Outils ou framework ?<br />Modèle intrusif ou pas<br />Solutions souvent techniques<br />Génération de code: templates dynamiques, CodeDom<br />Abstraction: proxy dynamique, tissage<br />
  5. 5. Introduction<br />Idéal ?<br />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.<br />La solution assure en général l’accès à la base et la création automatiques des objets (classFactory).<br />Les solutions sont en général riches mais coûteuses en ressources et en performances.<br />Data base<br />Objects<br />Mapping O/R<br />
  6. 6. Introduction<br />Réalité<br />De nombreuses solutions ont le parti pris de se baser soit sur la base soit sur les objets. <br />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)<br />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é <br />Data base<br />Objects<br />Mapping O/R<br />Infos de mapping<br />Infos de mapping<br />
  7. 7. Etat de l’art: les générateurs<br />Database Centric: type Olymars<br />Générateur<br />Développement<br />Exécution<br />Data base<br />Objects<br />Infos de mapping<br />
  8. 8. Etat de l’art: les générateurs<br />Object Centric: type DTM (Evaluant)<br />Générateur<br />Développement<br />Exécution<br />Data base<br />Objects<br />Infos de mapping<br />
  9. 9. Que recherchons nous vraiment ?<br />Automatisation de la DAL<br />Performance<br />Consommation mémoire<br />Productivité<br />Outil de conception<br />Abstraction de la base<br />Gestion du changement<br />?<br />Constat<br /><ul><li>Nous avons tous des attentes différentes
  10. 10. Nous savons que cette couche est déterminante
  11. 11. Beaucoup de solutions et beaucoup de polémiques</li></li></ul><li>Demo<br />Sans rien…<br />
  12. 12. Modélisation<br />Base de données<br />Tables, colonnes, types simples<br />Clés: primaires, étrangères, composites, indexes<br />Relations<br />Héritage<br />Objets<br />Classes, champs, propriétés<br />Compositions (types complexes), portées<br />Relations<br />Héritage: relationnel ou non<br />Modèle physique et conceptuel<br />Les objets plus proches du modèle conceptuel<br />
  13. 13. Demo<br />…avec des objets<br />
  14. 14. Architecture<br />Organisation en couches<br />DAL: data abstraction layer<br />Business/Rules: couche métier<br />Présentation: interface utilisateur (windows/web, autre)<br />Distribution<br />Possibilité de distribuer la couche DAL: choix complexe et déterminant<br />Choix d’un modèle communiquant (MarshalByRef)<br />Choix d’un modèle externe: sérialisation personnalisée ou génération d’un modèle communiquant<br />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é<br />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 »)<br />
  15. 15. Architecture<br />Modèles d’implémentation<br />Modèle répétitif<br />Chaque couche définit ses objets/interfaces:<br />Avantages: indépendance totale<br />Inconvénients: gourmand et complexe<br />Modèle navigant<br />Les différentes couches d’échangent un unique objet persistant<br />Avantages: un seul objet à concevoir, pas de duplication mémoire, simple<br />Inconvénients: dépendance entre les couches (l’abstraction via des interfaces permet au moins de libérer la dépendance binaire)<br />Enjeux<br />Concevoir dès la phase de définition d’architecture la nature précise de cette couche<br />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.<br />
  16. 16. Demo<br />Organisation en couches<br />
  17. 17. Fonctionnalités attendues de la couche objet<br />Données<br />Relations/Navigation<br />Requêtes<br />Transaction<br />Cache<br />Mise en œuvre <br />
  18. 18. Fonctionnalités attendues de la couche objet:Données<br />Gestion de la nullité: data == System.DBNull.Value ?<br />Object: boxing/unboxing (non typé)<br />SqlTypes<br />Nullables: int?<br />Projection variable<br />Associer des chargements de colonnes variables dans vers une même classe: « SELECT FIELD1, FIELD2,…, FIELDN FROM… »<br />Le « SELECT * » n’est pas toujours faisable (données trop grandes, blob), modifier le modèle n’est pas la solution<br />Versionning de données<br />Pouvoir jongler avec plusieurs jeux de données d’un même objet: AcceptChanges/RejectChanges<br />
  19. 19. Demo<br />Gestion de la nullité<br />
  20. 20. Demo<br />Versionning<br />
  21. 21. Fonctionnalités attendues de la couche objet:Données<br />Suivi des modifications<br />Mettre en œuvre un moyen de tracer toutes les modifications sur les objets persistants:<br />Notification au niveau des propriétés: pattern « PropertyNameChanged », INotifyPropertyChanged<br />Notification sur les collections: CRUD (Create, Update, Delete)<br />Le système est coûteux et non générique même s’il y a un mieux avec INotifyPropertyChanged (.Net 2.0)<br />Databinding<br />En WinForms ou WebForms<br />Le mapping objet relationnel tente d’automatiser la DAL, essayons de ne pas perdre le databinding !<br />Respect des interfaces de binding: IList, IBindingList, etc…<br />
  22. 22. Demo<br />Suivi des changements<br />
  23. 23. Fonctionnalités attendues de la couche objet:Relations/Navigation<br />Navigation<br />Chargements en cascade<br />LazzyLoading<br />Chargement à la demande lors de la navigation: client.Orders[0].Date<br />Paramétrage<br />Collections<br />Chaînage des appels entre collections et éléments<br />Intégrité<br />Profiter des informations relationnelles de mapping pour valider l’intégrité d’un graphe d’objet (de nombreuses notifications sont alors nécessaires)<br />
  24. 24. Fonctionnalités attendues de la couche objet:Requêtes<br />Génération automatiques des requêtes CRUD<br />Dynamique: à la demande<br />Statique: lors de la génération (si le modèle le propose)<br />Problématiques<br />Performance ?<br />Procédures stockées, vues ?<br />Accès total à la vue physique de la base de données: sécurité ?<br />Sémantique<br />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 ? <br />
  25. 25. Fonctionnalités attendues de la couche objet:Transaction<br />Possibilité de travailler de manière transactionnelle sur un graphe d’objets persistants<br />Notion de session nécessaire même dans un environnement non distribué<br />Isolation des modifications par client (idem base de données)<br />Implémentation des actions Commit et Rollback sur le graphe<br />Nouveauté<br />Profiter du namespace System.Transaction de .Net 2.0<br />Exemple de dataset transactionnel: http://www.techheadbrothers.com/DesktopDefault.aspx?tabindex=1&tabid=7&AId=120<br />
  26. 26. Fonctionnalités attendues de la couche objet:Cache<br />Les solutions de mapping O/R imposent par définition le mode déconnecté<br />Créer ou ne pas recréer un objet déjà chargé ? Avantages et inconvénients<br />Une ClasseFactory facilite normalement le branchement d’un cache d’objet (unicité de la création)<br />Définir les données du cache, sa stratégie<br />Versionning<br />Exemple de mise en œuvre<br />A la limite du garbage collector<br />
  27. 27. Demo<br />Mise en œuvre d’une solution de cache<br />
  28. 28. Fonctionnalités attendues de la couche objet:Mise en œuvre<br />Mapping<br />Par attributs<br />Avantages: lié au code, intégrité<br />Inconvénients: lié au code<br />Par fichier externe<br />Avantages: indépendance du code, possibilité de fournir plusieurs versions<br />Inconvénients: pas intègre<br />Ajout de fonctionnalités<br />Par classe partielle: facile mais non objet<br />Par héritage: classe de base<br />AOP:<br />Dynamique, par interception: MarshalByRef<br />Par tissage: AOP<br />
  29. 29. Demo<br />Interception de méthode: MarshalByRef<br />
  30. 30. Demo<br />Premier mapping<br />
  31. 31. Productivité<br />Outils<br />Externalisation des informations: mapping, méta-données<br />Générateurs: de schémas de base de données, de classes<br />Conception visuelle<br />Extensibilité de Visual Studio<br />Addins<br />Wizards<br />Designers<br />Project & item templates<br />
  32. 32. MySolution: DSMap, un DataSet objet ?!?!<br />Pourquoi développer sa propre solution:<br />Appréhender la difficulté ?<br />Mettre en place une solution originale ?<br />Etre plus apte à juger les produits existants ?<br />Conclure qu’il vaut mieux utiliser une solution du marché ?<br />Coller au mieux à ses besoins ?<br />Vous faire partager l’expérience<br />Se coller des cernes la veille d’une présentation technique rue de l’Université ?<br />
  33. 33. Solution proposée : objectifs<br />Avoir une solution indépendante de la source de données<br />Etre proche de la performance et de la consommation mémoire d’un modèle RAD avec chargement direct dans un DataSet<br />Conserver les fonctionnalités de « DataBinding » et d’utilisation en mode « design »<br />Fournir à la couche métier une unique interface d’accès aux données entièrement objet<br />
  34. 34. Solution proposée : avantages<br />Solution entièrement .Net car s’appuyant sur les DataSets.<br />Modèle indépendant de la source de données (base, xml, mémoire).<br />Chargement unique des données en mémoire dans un DataSet, le reste des classes persistantes offrant uniquement des accesseurs.<br />
  35. 35. Solution proposée : avantages<br />Création entièrement dynamique des collections et des éléments lors d’un parcours d’un graphe d’objets.<br />Plusieurs modes de création automatique des objets : systématique, cache.<br />Avoir des accesseurs non publics, en lecture, écriture ou lecture/écriture<br />
  36. 36. Solution proposée : avantages<br />Charger un nombre de colonnes variable dans un même objet mappé<br />Support du foreach pour les collections<br />Support du DataBinding des objets et des collections<br />Support du binding complexe vers les propriétés et les sous-propriétés d’un objet persistant (DataMember)<br />
  37. 37. Solution proposée : avantages<br /><ul><li>Héritage de classes
  38. 38. Support des collections hétérogènes avec classes héritées
  39. 39. 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)</li></li></ul><li>Solution proposée : contraintes<br />Solution entièrement .Net car s’appuyant sur les DataSets<br />Classes de base imposées pour les collections et les éléments<br />Chargement des clés primaires et étrangères obligatoires<br />
  40. 40. Demo<br />Rappels<br />
  41. 41. Solution proposée : architecture<br />Infos mapping<br />Commands,<br /> DataAdapters<br />Infos mapping<br />RelationalDataAdapter<br />CRUD<br />DataMapping<br />Infos mapping<br /><ul><li>par attributs
  42. 42. Par code</li></ul>IDBContext<br />DBContext<br />IDataSetProvider<br />IAutoUpdate<br />Mauvaise nouvelle<br />IL FAUT CODER !!!<br />Data base<br />Xml<br />DataSet<br />Objects<br />Mémoire<br />SqlDBContext<br />OracleDBContext<br />ADODBContext<br />
  43. 43. DataTable<br />DataSet<br />Solution proposée : architecture<br />DataClassCollection<br />DataClass<br />Property<br />DataTable<br />Data source<br />DataTable<br />DataView<br />Field<br />DataRowView<br />(Client)<br />(Client.Nom)<br />(Clients[])<br />
  44. 44. Solution proposée : architecture<br />dataView[]<br />DataRowView<br />DataClass IList.this[int index]<br />DataRowView<br />DataRowView<br />Réécriture de l’interface IList afin de retourner une instance de DataClass au lieu de DataRowView.<br />class Client :<br />DataRowView row<br />[DataClass(«ID»)]<br />class ClientCollection :<br />DataClassCollection,<br />IEnumerable, ICollection, IList<br />Client this[int index] {<br /> get {<br /> return GetItem(index);<br /> }<br />}<br />DataClass<br />String Nom {<br /> get {<br /> return row[«NAME»];<br /> }<br />}<br />
  45. 45. Solution proposée :mapping simple<br />Client : DataClass<br />String Nom<br />{<br /> get <br /> {<br /> return (string) row[«NAME»];<br /> }<br /> set<br /> {<br /> row[«NAME»] = value;<br /> }<br />}<br />
  46. 46. Solution proposée :mapping de relations<br />Client : DataClass<br />[DataClassRelation("customerid", "customerid")]<br />public CommandeCollection Commandes <br />{<br /> get<br /> { <br /> return (CommandeCollection) this.relations["Commandes"];<br /> }<br />}<br />[DataClassRelation(“(customerid=@custumerid) and (state = 1)")]<br />public CommandeCollection CommandesLivrees <br />{<br /> get<br /> { <br /> return (CommandeCollection) this.relations["Commandes"];<br /> }<br />}<br />
  47. 47. Solution proposée :mapping de références<br />Commande : DataClass<br />[DataClassReference("customerid", "customerid")]<br />public Client Client <br />{<br /> get { return (Client) this.references["Client"]; }<br />}<br />
  48. 48. Demo<br />DSMap<br />
  49. 49. Questions/Réponses<br />
  50. 50. © 2004 Microsoft Corporation. All rights reserved.<br />This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.<br />

×