La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Mapping objet relationnel Mitsuru FURUTA – Microsoft France

Présentations similaires


Présentation au sujet: "Mapping objet relationnel Mitsuru FURUTA – Microsoft France"— Transcription de la présentation:

1 Mapping objet relationnel Mitsuru FURUTA – Microsoft France

2 Objectifs de la présentation Cest 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… Cest 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 dautomatiser 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 Data base Objects Mapping O/R 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 laccè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.

6 Introduction Data base Objects Mapping O/R 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 sutilisent dans la phase de développement. Ils offrent un meilleur niveau de performance en contre partie dun certain nombre de restrictions sur le modèle généré Infos de mapping

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

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

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 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 dun modèle communiquant (MarshalByRef) Choix dun modèle externe: sérialisation personnalisée ou génération dun modèle communiquant Cette possibilité est souvent ignorée. Il devient pourtant rapidement tentant doffrir cette couche basse de larchitecture au reste dun 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 dimplé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 (labstraction via des interfaces permet au moins de libérer la dépendance binaire) Enjeux Concevoir dès la phase de définition darchitecture 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 dune architecture dimplé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 * » nest pas toujours faisable (données trop grandes, blob), modifier le modèle nest pas la solution Versionning de données Pouvoir jongler avec plusieurs jeux de données dun 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 sil y a un mieux avec INotifyPropertyChanged (.Net 2.0) Databinding En WinForms ou WebForms Le mapping objet relationnel tente dautomatiser 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 lintégrité dun graphe dobjet (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 dobjets 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: bindex=1&tabid=7&AId=120 bindex=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 dun cache dobjet (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 dune 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 quil vaut mieux utiliser une solution du marché ? Coller au mieux à ses besoins ? Vous faire partager lexpérience Se coller des cernes la veille dune présentation technique rue de lUniversité ?

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 dun modèle RAD avec chargement direct dans un DataSet Conserver les fonctionnalités de « DataBinding » et dutilisation en mode « design » Fournir à la couche métier une unique interface daccès aux données entièrement objet

33 Solution proposée : avantages Solution entièrement.Net car sappuyant 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 dun parcours dun graphe dobjets. 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 dun 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 sappuyant 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 Solution proposée : architecture Objects DataSet Xml Mémoire Commands, DataAdapters Infos mapping DBContext CRUD Data base RelationalDataAdapter Infos mapping Mauvaise nouvelleIL FAUT CODER !!! DataMapping Infos mapping -par attributs -Par code SqlDBContextOracleDBContextADODBContext IDBContext IDataSetProvider IAutoUpdate

40 DataTable DataSet Solution proposée : architecture Data source DataViewField DataClassCollectionDataClassProperty DataRowView (Clients[]) (Client)(Client.Nom)

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

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"]; } 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.


Télécharger ppt "Mapping objet relationnel Mitsuru FURUTA – Microsoft France"

Présentations similaires


Annonces Google