octobre
2008
Comme je vous le disais dans mon précédent article, la suite de cette série est basée sur la documentation de tiOPF par TechInsite.
Vous trouverez ci-dessous une traduction très libre et commentée du chapitre d’introduction de « tiOPF Concepts Manual », qui résume le contenu du document et qui nous servira de fil conducteur pour le développement de l’exemple « Repertoire ». Je ne suivrai cependant pas strictement le plan du manuel de TechInsite pour la présentation des mécanismes de persistance des objets.
1 – Qu’est-ce qu’un OPF
J’ai choisi de conserver l’abréviation anglo-saxonne OPF (Object Persistence Framework) plutôt que d’introduire un nouveau sigle pour désigner une Architecture de Persistance des Objets. Mais laissons la parole aux développeurs de TechInsite :
» Dans ce chapitre nous examinerons en quoi consiste une architecture de persistance des objets (OPF) et comment elle peut vous aider à construire de meilleures applications de bases de données. Nous y exposerons quelques problèmes inhérents aux applications construites avec une approche RAD (Rapid Application Design : construction rapide d’applications) qui est le propre de Delphi. Nous verrons aussi comment un OPF peut contribuer à résoudre, au moins partiellement, ces problèmes.
Nous y examinerons aussi rapidement les règles de conception d’un OPF telles que définies dans le projet Jedi-Obiwan (un projet open source qui se propose de construire l’OPF ultime pour Delphi), et par Scott Ambler (expert OPF reconnu, auteur de nombreux articles sur le sujet) []. »
Pour ma part, je ne m’étendrai pas sur le sujet.
Il n’est cependant pas exclu que je vous propose ultérieurement une traduction de ce chapitre, mais ce n’est pas la priorité du moment.
2 – Visitor pattern
« Le but de ce chapitre est de proposer un modèle générique pour l’exécution d’une série de tâches corrélées sur des éléments d’une liste d’objets. La tâche exécutée peut être différente selon l’état interne de chaque élément. Il se peut que nous ne fassions rien du tout, ou que nous exécutions une multitude de tâches sur une multitude d’éléments. Nous utiliserons le « Visitor pattern », le modèle « Visiteur » du Gang of Four (GoF) pour répondre à cette contrainte, et nous verrons comment un « Visitor » peut être utilisé pour sauvegarder des objets dans différents formats de fichiers-textes. »
Le « Visitor pattern » appliqué à la persistance des objets à l’aide de fichiers-textes sera donc le premier sujet que je traiterai exhaustivement dans cette série d’articles.
3 – « Visitor pattern » et SQL
« La plupart des applications d’entreprise utilisent une base de données relationnelle pour stocker les données. C’est pourquoi, dans ce chapitre, nous étendrons le modèle Visiteur du chapitre 2 au stockage dans une base de données Interbase. Nous étendrons le modèle Visiteur à l’aide du modèle « Template Method » pour réaliser la sauvegarde des objets dans une base de données relationnelle. »
Encore un sujet que je me propose de traiter en long et en large, en détaillant méthodiquement la démarche. Avec une nuance cependant : j’utiliserai le SGBD Firebird, le clone open-source d’Interbase.
4 – Composite pattern et objets du domaine
… ou « Building an abstract business object model with the Composite pattern » en VO.
La traduction compacte du titre de ce chapitre est une gageure. Il s’agit ici de construire une architecture abstraite d’objets pour le domaine de l’application, et d’utiliser le modèle « Composite » du GoF pour réaliser cela.
Voici ce que disent les auteurs :
« Dans les chapitres 2 et 3, nous avons commencé à développer une classe abstraite « collection », et une classe abstraite d’objets du domaine. Dans le chapitre 4, nous étendrons ces classes en y ajoutant quelques-unes des fonctionnalités dont nous aurons besoin pour construire un système de gestion complexe. »
Le système de gestion complexe, un ERP par exemple (système intégré de gestion pour la comptabilité, la paie, les stocks, etc), peut contenir des centaines de classes (que nous avons aussi désignées ci-dessus comme les classes du domaine de l’application). Toutes ces classes héritent de classes abstraites qui définissent les fonctionnalités communes à toutes les classes du domaine. Ces classes abstraites font partie du framework de persistance (OPF) et doivent être adaptées à n’importe quel domaine (par exemple une gestion de bibliothèque, au lieu d’un ERP).
5 – Un exemple d’utilisation de tiOPF
« Dans ce chapitre nous utiliserons le framework (qui peut être téléchargé en même temps que tiOPF), pour construire une application de gestion de contacts réaliste. Nous utiliserons UML pour modéliser l’architecture des objets du domaine (Business Object Model). Puis nous construirons une interface-utilisateur (GUI) en utilisant les composants d’accès aux objets de la classe TPersistent fournis avec tiOPF. Nous terminerons par l’étude de trois stratégies pour relier les objets à une base de données (mapping objet-relationnel) en utilisant le gestionnaire de persistance (persistence manager) inclus dans le framework. »
Il n’est cependant pas exclu que je vous propose ultérieurement une traduction de ce chapitre. Mais la mise en oeuvre de tiOPF sort du cadre de cette série d’articles.
6 – « Adaptor pattern » et indépendance par rapport au SGBD
« tiOPF permet de se connecter à différents SGBD utilisant différentes API, juste en modifiant un paramètre de ligne de commande. Cela s’obtient en encapsulant les composants de connection comme TDatabase et TQuery, puis en mettant en oeuvre le modèle « Factory » pour construire les composants concrets appropriés. Cette technique s’appuie sur le modèle « Adaptator » du GoF et est explicitée dans ce chapitre. »
Cette technique sera développée à la fin de la série d’articles sur l’OPF.
7 – Références et bibliographie
« Ce chapitre contient les liens vers la dernière version de ce document, le code source de tiOPF, ainsi que des articles et des publications qui ont été utilisés comme base de tiOPF. Le forum, les listes de diffusion et les outils qui ont servi pour le développement de tiOPF sont également référencés. »