Mapping objet relationnel Mitsuru FURUTA – Microsoft France mitsufu@microsoft.com .

Post on 03-Apr-2015

134 views 0 download

Transcript of Mapping objet relationnel Mitsuru FURUTA – Microsoft France mitsufu@microsoft.com .

Mapping objet relationnel

Mitsuru FURUTA – Microsoft Francemitsufu@microsoft.com http://blogs.microsoft.fr/mitsufu

Objectifs de la présentation

C’est une présentation technique !Appréhender les conceptsComprendre les problématiquesEtre capable d’évaluer un produitMettre en œuvre les principes fondamentaux sous forme de courtes démos

Pas de présentation de produitPas de parti prisPas de LINQ…C’est une présentation technique !

Mapping objet relationnel

Introduction

Modélisation

Architecture

Fonctionnalités attendues de la couche objet

Productivité

MySolution: DSMap, un DataSet objet…

La pause ? Quelle pause ?La pause ? Quelle pause ?

Introduction

Enjeux et problématiquesDatabase != objectsArchitecture multi-couche: DAL, business, présentation

Est-il possible d’automatiser la DAL ?Amener la persistance aux objets métiers

ModélisationRecherche du modèle unique

RequêtageTuer le SQL

ImplémentationsOutils ou framework ?

Modèle intrusif ou pas

Solutions souvent techniquesGénération de code: templates dynamiques, CodeDomAbstraction: proxy dynamique, tissage

Introduction

Data base ObjectsMapping 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 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.

Introduction

Data base ObjectsMapping 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 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é

Infos de mapping

Infos de mapping

Etat de l’art: les générateurs

Data base Objects

Database Centric: type Olymars

Infos de mapping

GénérateurDéveloppement

Exécution

Etat de l’art: les générateurs

Data base Objects

Object Centric: type DTM (Evaluant)

Infos de mapping

GénérateurDéveloppement

Exécution

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

Sans rien…

DemoDemo

Modélisation

Base de donnéesTables, colonnes, types simplesClés: primaires, étrangères, composites, indexesRelationsHéritage

ObjetsClasses, champs, propriétésCompositions (types complexes), portéesRelationsHéritage: relationnel ou non

Modèle physique et conceptuelLes objets plus proches du modèle conceptuel

…avec des objets

DemoDemo

Architecture

Organisation en couchesDAL: data abstraction layer

Business/Rules: couche métier

Présentation: interface utilisateur (windows/web, autre)

DistributionPossibilité 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 »)

Architecture

Modèles d’implémentationModèle répétitif

Chaque couche définit ses objets/interfaces:Avantages: indépendance totale

Inconvénients: gourmand et complexe

Modèle navigantLes 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)

EnjeuxConcevoir 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.

Organisation en couches

DemoDemo

Fonctionnalités attendues de la couche objet

Données

Relations/Navigation

Requêtes

Transaction

Cache

Mise en œuvre

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 variableAssocier 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éesPouvoir jongler avec plusieurs jeux de données d’un même objet: AcceptChanges/RejectChanges

Gestion de la nullité

DemoDemo

Versionning

DemoDemo

Fonctionnalités attendues de la couche objet:Données

Suivi des modificationsMettre en œuvre un moyen de tracer toutes les modifications sur les objets persistants:

Notification au niveau des propriétés: pattern « PropertyNameChanged », INotifyPropertyChangedNotification 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)

DatabindingEn 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…

Suivi des changements

DemoDemo

Fonctionnalités attendues de la couche objet:Relations/Navigation

NavigationChargements en cascade

LazzyLoadingChargement à la demande lors de la navigation: client.Orders[0].Date

Paramétrage

CollectionsChaî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)

Fonctionnalités attendues de la couche objet:Requêtes

Génération automatiques des requêtes CRUDDynamique: à la demande

Statique: lors de la génération (si le modèle le propose)

ProblématiquesPerformance ?

Procédures stockées, vues ?

Accès total à la vue physique de la base de données: sécurité ?

SémantiqueAvoir 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 ?

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

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 œuvreA la limite du garbage collector

Mise en œuvre d’une solution de cache

DemoDemo

Fonctionnalités attendues de la couche objet:Mise en œuvre

MappingPar attributs

Avantages: lié au code, intégritéInconvénients: lié au code

Par fichier externeAvantages: indépendance du code, possibilité de fournir plusieurs versionsInconvénients: pas intègre

Ajout de fonctionnalitésPar classe partielle: facile mais non objetPar héritage: classe de baseAOP:

Dynamique, par interception: MarshalByRefPar tissage: AOP

Interception de méthode: MarshalByRef

DemoDemo

Premier mapping

DemoDemo

Productivité

OutilsExternalisation 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 StudioAddins

Wizards

Designers

Project & item templates

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é ?

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

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.

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

Solution proposée : avantages

Charger un nombre de colonnes variable dans un même objet mappéSupport du foreach pour les collectionsSupport du DataBinding des objets et des collectionsSupport du binding complexe vers les propriétés et les sous-propriétés d’un objet persistant (DataMember)

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)

Solution proposée : contraintes

Solution entièrement .Net car s’appuyant sur les DataSetsClasses de base imposées pour les collections et les élémentsChargement des clés primaires et étrangères obligatoires

Rappels

DemoDemo

Solution proposée : architecture

ObjectsDataSet

Xml

Mémoire

Commands, DataAdapters

Infos mapping

DBContext

CRUD

Data base RelationalDataAdapter

Infos mappingMauvaise nouvelleIL FAUT CODER !!!

DataMapping

Infos mapping-par attributs-Par code

SqlDBContextOracleDBContext ADODBContext

IDBContextIDataSetProviderIAutoUpdate

DataTableDataTable

DataTableDataSet

Solution proposée : architecture

Data sourceDataView Field

DataClassCollection DataClass Property

DataRowView

(Clients[]) (Client) (Client.Nom)

Solution proposée : architecture

DataClass

class ClientCollection : DataClassCollection,

DataRowViewDataRowView

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 l’interface IList afin de retourner une instance de DataClass au lieu de DataRowView.

[DataClass(«ID»)]

Solution proposée :mapping simple

Client : DataClass

String Nom{ get { return (string) row[«NAME»]; } set { row[«NAME»] = value; }}

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

Solution proposée :mapping de références

Commande : DataClass

[DataClassReference("customerid", "customerid")]public Client Client { get { return (Client) this.references["Client"]; }}

DSMap

DemoDemo

Questions/RéponsesQuestions/Réponses

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