Les news d'Aspectize : EntityDesigner

La quadrature du cercle

Nico — Wed, 02 Sep 2009 11:11:00 GMT

La quadrature du cercle est un problème classique de géométrie, qui consiste à construire un carré de même aire qu'un cercle donné à l'aide d'une règle et d'un compas. Il remonte à l'invention de la géométrie et a occupé de nombreux mathématiciens au cours des siècles. Grégoire de Saint-Vincent était passionné par le problème : estimant — à tort — l'avoir résolu, il exposa ses solutions dans un ouvrage de 1 000 pages. C'est en 1837 que Pierre-Laurent Wantzel démontre un théorème qui permet d'exhiber la forme des équations dont sont solutions les nombres constructibles à la règle et au compas. Puis en 1844, Joseph Liouville met en évidence l'existence des nombres transcendants. Mais il faudra attendre jusqu'en 1882 pour que le mathématicien allemand Ferdinand von Lindemann démontre la transcendance de π pour appliquer le théorème de Wantzel au problème de la quadrature du cercle et ainsi démontrer qu'elle est impossible à réaliser. L'Académie des sciences, qui avait déjà pressenti ce résultat un siècle auparavant, n'acceptait plus de « preuve » de cette quadrature depuis 1752.

La quadrature du cercle nécessite en effet la construction à la règle et au compas de la racine carrée de π, ce qui est impossible en raison de la transcendance de π : les nombres constructibles sont les rationnels et les racines de certains polynômes de degré 2n à coefficients entiers, ce sont des nombres algébriques ce qui n'est pas le cas de π. (source wikipedia).

L'ORM est un problème classique de l'industrie logicielle, qui consiste à faire cohabiter un modèle relationnel et un modèle objet. Il est issu de l'omniprésence des bases de données relationnelles, et de l'approche orientée objet, communément pratiquée dans le monde du développement. Pourtant ces 2 mondes reposent sur des approches différentes. Le modèle relationnel est fondé sur la théorie des ensembles, l'algèbre relationnelle, et la logique formelle. Il permet d'appliquer des processus de normalisation qui garantissent la non-redondance des données. Le modèle objet est fondé essentiellement sur les concepts d'Identité, d'Etat, de Comportement et d'Encapsulation.

Les principales zones de frottement sont notamment les suivantes:

inadéquation de la relation d'association: dans une base de données, une relation est bidirectionnelle et s'implémente par une Foreign Key, une colonne qui pointe vers une l'identifiant d'une autre Entité; dans un modèle objet, elle n'est pas nécessairement bi-directionnelle et s'implémente par un pointeur vers une autre structure fortement typée.
inadéquation de l'héritage avec la logique relationnelle.
inadéquation entre l'identité de l'objet et l'identité en base.

L'objectif des 2 modèles est pourtant bien le même: représenter les informations du monde réel, l'un pour le stockage, l'autre pour les traitements et l'affichage. Mais leur différence d'approche fait que la friction entre les 2 modèles ne peut se faire sans heurts: de la même manière que la transcendance de π démontre l'impossibilité d'une solution pour le problème de la quadrature du cercle, "l'Impedence Mismatch" rend impossible la cohabitation. L'usage d'un ORM sera aussi compliqué qu'approximatif; il suffit de lire Ted Neward et de regarder les nombreuses tentatives vaines de Microsoft sur le sujet (Object Spaces, Active Recordsets, LINQ to SQL et Entity Framework) pour s'en convaincre. Et tous les spécialistes d'NHibernate vous le diront, "c'est une affaire de spécialistes !" et on ne peut pas mettre cet outil entre toutes les mains.

Alors que faire ? Il n'y a pas moultes solutions, il faut faire des sacrifices d'un côté ou de l'autre.

Solution 1: utiliser une base de données orientées objet, afin de rendre compatible l'approche utilisée par le développement et l'approche utilisée par le stockage. Mais l'histoire a montré que les bases de données orientées objet présentaient une complexité d'usage que n'ont pas les SGBDR, tandis que ceux-ci offraient au même moment une facilité de compréhension des concepts et des performances bien meilleures.

Solution 2: abandonner les concepts de l'approche objet qui sont en conflit avec l'approche relationnelle et garder dans son développement la logique relationnelle. On va bien sur utiliser des objets fortement typés dans leur déclaration pour faciliter la programmation, le langage et l'outil de développement sont bien adaptés pour le faire, mais on va préférer

une approche Entiés/Relations où les Entités sont indépendantes les unes des autres, et la relation qui joue le rôle de lien entre les Entités. Le frottement n'en sera que moins douloureux. Une Entité en mémoire ne connait pas la structure des Entités avec lesquelles elle est reliée. C'est la relation qui lui permet d'accéder a ses entités reliées, et qui garantit le caractère bi-directionnel de l'association entre les entités. Cela permet également d'avoir une implémentation invariante de la cardinalité et de faciliter la gestion du cycle de vie des entités, avec un contrôle total sur le LazyLoading.
abandonner purement et simplement l'Héritage (et indépendamment du sujet ORM, vous ne vous en porterez que mieux pour maintenir votre système !) Une approche de la conception par composition sera bien plus efficace à long terme.
ne pas mettre de comportement dans les Entités, et préférer une approche Service StateLess; la notion d'identité de l'instance perd alors son importance.
avoir des identifiants uniques sur les Entités, de type Guid. C'est l'identifiant technique qui jouera le rôle de clé primaire dans la base. Et ne surtout pas prendre des Int autoincrémenté, qui mettent une dépendance forte entre le stockége physique et l'allocation d'un nouvel identifiant.

Bien entendu, cette deuxième approche n'est pas immédiate, et elle remet en cause beaucoup de choses que les architectes/développeurs ont l'habitude de pratiquer. C'est néanmoins les choix que nous avons faits pour notre couche d'accès aux données. En prenant cette approche, nous avons résolu et facilité un bon nombre de problèmes posés par l'incompatibilité des 2 mondes et nous disposons d'un ORM facile à utiliser et puissant.

Nous y reviendrons dans les prochains jours, quand la bête sera disponible...

Schema et accès aux données

Nico — Wed, 25 Mar 2009 08:32:00 GMT

Cet article a pour objectif de décrire notre approche à propos de l'accès aux données.

En préambule, un petit aparté sur Entity framework, qui s'inscrit dans la continuité de l'histoire douloureuse des ORM de Microsoft.

Microsoft a sorti en 2008 la V1 d'Entity Framework. Elle a suscité de nombreuses réactions, plutôt négative de la communauté. Trop intrusif, trop de code à écrire, trop compliqué à utiliser, trop d'inconvénients pour peu de bénéfices. Microsoft a écouté, et a décidé de construire la V2, en transparence, et en communiquant au fur et à mesure de son évolution. Ca se passe ici, sur le blog de l'équipe d'EF, et la Wish list (77 pages de Forums !) s'est arrêtée au 15 janvier.

Malgré cela, l'approbation de la communauté n'est pas encore gagné.

Un article évoque la gestion du ChangeTracking, fonctionnalité inhérente à tout ORM qui se respecte. Ils ont plus ou moins décidé qu'ils allaient fournir des API pour que les développeurs implémentent eux-mêmes leur gestion du ChangeTracking: que de choses à connaître, et que de code à écrire.

Autre exemple, la gestion des Foreign Keys. Apparemment, certains voudraient voir les FK dans leurs entités, et d'autres non, car ils considèrent que l'entité est polluée par une FK. D'où une gestion de FK hybride, les Independant Associations apportées par .Net 4.0; encore quelque chose de compliqué et d'artificiel qui nécessitera apprentissage.

Alors que l'usage du DataSet simplifierait les problèmes, ils évitent soigneusement de l'utiliser, avec des arguments discutables.

Sami Jabber a parfaitement raison quand il écrit à propos d'Entity FrameWork: "Un modèle conceptuel de données qui permet d'abstraire du XML, du relationnel, de l'objet et des DataServices (pour Astoria) a un nom, cela s'appelle de la magie noire".

Notre vision est nettement plus simple, pragmatique, compréhensible tant pour sa lecture, que pour son utilisation, souple, dynamique, peu intrusif, et requiert l'écriture d'un minimum de code.

Des données relationnelles sont persistées quelque part (un fichier, une base de données ? peu importe !), et il serait pratique d'y avoir accès "facilement". Inversement, des données relationnelles sont en mémoire, et on souhaite les persister quelque part (un fichier, une base de données ? peu importe !), sans trop d'efforts. J'insiste sur le caractère relationnel des données, car c'est le coeur du problème, ou plutot le coeur de la solution.

Plus précisément, on souhaite écrire le moins de code possible (évitons le SQL) et ne pas être intrusif vis-à-vis des Entités que l'on manipule.

Et s'il n'y a pas de solution magique, je maintiens qu'il y a plus à gagner à utiliser le DataSet qu'à ne pas le faire. Et pas seulement pour le ChangeTracking, mais pour beaucoup d'autres; serialisation, dynamisme, filtre, tri, Merge, gestion événementielle.

Et s'il y a quelques défauts, essayons de les gommer, plutôt que de jeter le bébé avec l'eau du bain.

Intellisense: toujours difficile à concilier avec le dynamisme, nous apportons une solution. C'est du typage fort pour le code, côté serveur, et du typage dynamique pour le transport et le Binding, le mariage idéal des 2 mondes.
Validation: les ExtendedProperties permettent de stocker des attributs complémentaires et manquants. Des validateurs standards (Min, Max, Regex), mais aussi Custom avec des Commandes de Validation.
Navigation: quelques fonctions génériques de navigation, en fonction du typage fort, mais aussi du typage souple, permettent de naviguer de façon extrêmement conviviale et évite la manipulation verbeuse du DataSet qui fait souvent peur au développeur.

Aspectize Entity Designer est l'Outil de Design du modèle conceptuel des données, c'est à dire les Entités et les Relations. De ForeignKey, il n'est point question; nous insistons sur ce point, la Relation existe à part entière, c'est fondamental pour l'approche. Sa cardinalité est définie, mais elle n'a pas d'implication sur le modèle. Cela permet de garantir l'indépendance des Entités. Peu importe si ma Category est liée à un Product ou à autre Chose, cela n'influe pas la nature de mon Entité Category.

Nous pouvons ajouter de nombreux attributs :
- MustPersist: permet de dire si certaines Entités ou Champs ne sont pas sauvegardés. Pratique, quand certaines entités ne servent qu'au calcul ou a l'IHM. A noter que les Relations peuvent également être non persistence.
- Validators: permet de définir un Validateur, écrit en .Net, qui sera toujours appelé lors d'un CommandBinding configuré sur cette commande.
- Triggers: permettent de définir des commandes qui seront automatiquement appelées lorsque l'on impactera une Entité, en fonction du State (Add, Delete, Update).

Un des attributs les plus intéressant est sans doute le Temporel, qui permet de définir automatiquement la dépendance au temps d'une donnée: dans mon exemple, le prix du produit est historisé, et est donc stocké dans une autre table. L'intérêt de l'attribut Temporel est que cela est complètement transparent d'un point de vue logique: j'ajoute même un autre champ qui me permet d'avoir le prix courant, sans être obligé d'interroger systématiquement l'historique des prix.

EntityManager est notre composant d'accès aux données. Il permet, via une API extrêmement simple de faire tout ce qu'on veut pour récupérer des données et les sauvegarder.

IDataManager dm = EntityManager.FromDataBaseService("MyDataService");

Pour récupérer une Category à partir de son Id:

Category category = dm.GetEntity<Category>(id);

ou tous les Product associés à une Category, selon la relation CategoryProduct (on pourrait imaginer avoir plusieurs relations entre les mêmes entités):

dm.GetAssociated<Product, CategoryProduct>(id);

Accessoirement, c'est la même API pour naviguer dans les données en mémoire, à partir du DataSet (ce qui évite la manipulation verbeuse):

List<Product> products = category.GetAssociatedInstances<CategoryProduct>();

Et pour la sauvegarde, c'est encore plus simple. La seule méthode Save, sauvegarde toutes les lignes du DataSet en fonction des changements:

dm.Save();

L'énorme avantage est de tirer parti à la fois du typage fort proposé par Entity Designer, et du typage dynamique géré par le DataSet.

Ainsi, le chargement d'une Category peut s'écrire également:

dm.LoadData("ADWData.Category[Id = id]");

ou avec les Product associés:

dm.LoadData("ADWData.Category[Id = id].CategoryProduct.Product");

mais aussi ajouter un nouveau Product à une Category:

uiService.AddRow("ADWData.Category.CategoryProduct.Product");

Il est du coup, extrêmement facile d'écrire des services d'accès aux données; nous verrons plus tard que nous n'avons même pas à écrire ces services d'accès aux données, car ils peuvent se déduire du DataBinding. L'Application charge toute seule les données qu'elle affiche, en fonction des DataBinding configurés sur les contrôles.

Difficile de faire plus simple; aucune intrusivité, tous les scénarios d'accès aux données Lazy ou non sont couverts, de façon extrêmement limpide et le DataBinding se charge du reste !

Entity Designer pour VS 2008

Nico — Tue, 06 May 2008 07:21:00 GMT

Pour être tout à fait complet sur l'intégration à Visual Studio, il manquait encore la version d'Entity Designer pour VS 2008.

C'est désormais chose faite, elle est disponible dans la version d'évaluation, en téléchargement.