l'Objet de données qui doivent être stockées dans une base de données. Cet article vous montre comment.
Objets Persistants
Dans les deux derniers articles, nous avons introduit les objets d'entreprise et montre comment de simples relations peuvent être représentées. Les relations exprimées comme des propriétés de l'objet sont un plus formel (et neutre) de la représentation des relations entre les entités de données qui peut être implicite dans la conception de base de données, ou explicite dans le schéma de base de données. En s'éloignant d'une centralisation de données en vue d'entités et de relations à un plus structurée, orientée objet, l'exposition présente de nombreux avantages, mais la plupart des langues (y compris Delphi) s'adressent uniquement pour un objet en mémoire les objets de modèle ont pas la persistance de l'état de la capacité, à moins que l'un est prévu pour eux.
Il existe de nombreuses solutions de conception de cette exigence, et nous avons déjà établi que l'entreprise (problème de domaine) les objets eux-mêmes ne doivent pas communiquer directement avec la base de données. Une conception appropriée est d'avoir un autre ensemble de classes qui existent uniquement comme un objet de l'interface de la base de données, et sera responsable pour le chargement et le problème d'enregistrement de domaine de l'état de l'objet. Notre problème objets de domaine ne sait rien sur la façon dont leur état est stocké sur le disque, mais seulement qu'il est une classe particulière qui est responsable de cette opération. Les objets d'affaires permettra de faire un appel de méthode sur un objet et déléguer le travail.
La première décision qui doit être prise est de décider comment les objets de la carte sur un schéma de base de données. Bien qu'un certain nombre d'objet bases de données existent, la plupart des entreprises ont standardisé sur un SGBDR avec qui ils sont à l'aise et expérimentés. La promotion d'un développement de la changer pour une plus approche orientée objet est assez difficile, sans exiger que les généralement de gros investissements dans un très évolué technologie de base de données est répliquée pour une nouvelle, inconnue. Par conséquent, cet article mettra l'accent sur la cartographie des objets à base SQL SGBD, ce qui constitue la majorité de installé des systèmes de développement. Il convient, toutefois, de souligner que l'un des avantages de notre modèle d'objet, c'est qu'il est totalement à l'architecture neutre et peut être appliquée à un grand nombre de différentes topologies de base de données, y compris ISAM et de l'objet.
Mappage des objets de bases de données
Il est évident et naturel qu'il est relativement simple conceptuel de la correspondance entre un objet et un tuple (record). Par conséquent, lorsque le stockage de l'état de l'objet dans un SGBD très commune, et pratique, la solution est de cartographier un problème de classes du domaine à des tableaux, des objets, des documents et des propriétés des champs. Notez que parce que notre base de données sera le stockage de l'état de l'objet, il doit être une représentation complète et, par conséquent, il est probable qu'il y aura plus de champs dans la table de base de données qu'une classe possède des propriétés publiques. Dans certains cas, un bien public ne peut pas avoir un correspondant directement champ, mais le principe général est de mapper une propriété sur un champ de base de données de semblable fondamental de type (caractère, numérique, date, etc.)
nous allons maintenant étendre notre cadre de base des classes pour objet le soutien de la persévérance. Notre problème objets du domaine (TPDObject) doivent permettre à d'autres classes à force de charger ou de sauvegarder leur état. Il y a un certain nombre d'autres façons d'aborder cette situation est de forcer tous les objets de façon implicite enregistrer leur état avant qu'ils soient détruits. Dans la pratique, les applications nécessitent un meilleur degré de contrôle sur le moment où l'état de l'objet doit être conservé et donc notre TPDObject gagnera deux nouvelles méthodes publiques, de Chargement et de sauvegarde. La méthode Save est sans paramètre, mais notre méthode de Chargement doit définir exactement quel est l'objet qui doit être chargé à partir de persistance. Dans notre cadre, tous les objets du domaine qui ont été enregistrés sont attribué un ID unique à l'intérieur d'un contexte donné (ce qui pourrait être à l'intérieur des objets de la même classe, les objets de la même ascendance, de l'application ou de l'universel). Nous allons utiliser cet ID en tant que paramètre à la méthode Load de standardiser les moyens par lesquels nous établir l'identité de l'objet. Notez que c'est toujours utilisée, même si une classe peut avoir une solution de rechange acceptable 'clé primaire' concept. La standardisation sur un seul concept de l'identité de l'objet est utile, comme notre cadre pouvez utiliser cette cohérence pour traiter notre problème objets de domaine générique, et polymorphe de la mode. Certains peuvent se demander la présence d'une propriété publique (quoique en lecture seule) qui expose un type choisi pour des raisons de commodité pour l'adapter à l'intérieur de notre cadre. Dans la pratique, l'identification des objets par ID est quelque chose qui se produit presque entièrement dans le cadre du code et est rarement rencontrée dans l'application de la logique elle-même. Au sein de cette arène, les objets sont manipulés à l'aide de concepts beaucoup plus familier pour les utilisateurs finaux, tels que 'l'ensemble des clients appelé Smith', plutôt que par les développeurs résumés.
après Avoir défini le public à l'interface de la méthode sur notre TPDObject domaine du problème de la classe, il nous faut maintenant envisager la mise en œuvre. En fait, c'est très simple. Nous avons déjà indiqué que l'objet de l'entreprise ne sait rien à propos de comment elle est stockée, mais seulement qu'il est un autre objet responsable de cette tâche. Par conséquent, la mise en œuvre de nos méthodes de persistance sur TPDObject simplement déléguer le travail à un autre objet référencé au sein d'un domaine privé. Chacun de ces appels de méthode est paramétré avec Soi-même, de sorte que le délégué objet sait avec quelle instance il a à faire. En effet, lorsqu'un problème de domaine objet est invité à enregistrer (ou de charge) lui-même, tout simplement, il indique un autre objet de 'save me'.
Gestion des Données
La tâche de l'économie de l'état de l'objet à une base de données tombe à un ensemble de classes dans la gestion des données de la couche. Comme prévu, nous aurons une hiérarchie de classes qui nous permet de fournir une importante base de données indépendante de la fonctionnalité. L'ensemble de nos classes responsable de la gestion des données de descendre d'un résumé TDMObject classe. Cette classe fournit un objet de base, de la base de données indépendante de l'interface pour les opérations de base de données. Base de données spécifique de soutien est fourni par la création d'un béton descendant de cette classe, qui fournit une connexion à la base de données de choix à l'aide de la technologie la plus appropriée, et fournit également certains services de base. Ces services de base sera totalement adapté aux caractéristiques spécifiques de la base de données concernée, et sera utilisé par l'application dépendant de descendants personnalisée pour le traitement d'un particulier TPDObject. Cette conception n'a pas à dicter les moyens par lesquels le TDMObjects communiquer avec le moteur de base de données: chaque couche de base de données est libre de choisir le plus approprié (plus facile et plus rapide) de la technologie disponible. Cela pourrait être ADO pour SQL Server 7, IBExpress pour Interbase, le BDE pour les fichiers Paradox, un API ou il est en effet possible de l'interface à quelque chose comme ODBC ou CORBA pour le générique de la manipulation. Ma préférence est d'optimiser la connexion à l'aide d'une base de données dépendante de la série de composants que ceux-ci sont généralement offrent le plus de fonctionnalités et de vitesse. Notez que la sélection d'une base de données dépendant de l'API de ne pas restreindre votre application en cours d'exécution avec cette base de données il est possible de remplacer une base de données dépendant de la TDMObject couche pour un autre. L'interface de la TDMObject est purement à base d'objets, de sorte qu'il ne peut être garantie qu'à condition de notre base de données des couches de mettre en œuvre les méthodes concrètes correctement, l'application fonctionnera à l'identique sans modifications.
La mise en œuvre effective de chaque base de données spécifique de la couche dépend de la base de données concernée, mais en général pour SQL capable de bases de données, il est utile de fournir un générique Exécuter la commande qui prend valide la commande SQL en tant que paramètre. Une fois que nous avons un TDMObject descendant d'une base de données choisie, nous devons fournir un certain nombre de descendants de cette classe, une pour chaque TPDObject dans notre application. Ils seront personnalisés pour gérer un très combinaison spécifique de l'économie d'une catégorie donnée dans une base de données particulière. Les détails de ces classes dépendent les fonctionnalités fournies par les données de la classe de gestion de la base de données particulière, mais une fonctionnalité est essentielle: l'opération d'enregistrement doit retourner l'ID de l'objet enregistré. La raison pour cela est que, dans notre modèle choisi, un TPDObject ne pas avoir une carte d'identité jusqu'à ce que la première fois qu'il est enregistré. Un avantage particulier de ce modèle est qu'il est très facile pour la gestion des données de la couche afin de détecter s'il est nécessaire de générer une INSERTION ou une mise à JOUR de base de données de type action. En général, l'attribution de la carte d'identité pourrait être fait par un autre objet conçu purement à cette fin, mais il est très bénéfique d'optimisation qui peut être fait, si nous nous appuyons sur notre gestion des données d'un objet pour en faire ce travail pour nous. N'oubliez pas que nos ID doit être unique dans un contexte donné, si le contexte choisi est que les objets de la même classe ont les ID unique, alors ce peut être assimilé à des enregistrements dans la table ayant les ID unique. La plupart des bases de données ont une certaine facilité pour la génération séquentielle ID unique pour les enregistrements insérés, et de faire de cette valeur disponible après la mise à jour de la base de données. À l'aide de ce dispositif dans notre gestion des données de couche peut éviter la réplication de l'effort pour garantir l'unicité, et dans le meilleur des cas peut enregistrer sur d'autres opérations de base de données pour établir le prochain ID. Si la base de données n'a pas un tel dispose alors d'un IDENTIFIANT interne d'allocation de régime au sein de la hiérarchie de la gestion des données peut être utilisé.
Listing 1 montre les extensions de notre Cadre de l'unité de soutien de Charger et d'Enregistrer des opérations, en collaboration avec le contour d'une classe permettant de gérer l'accès aux données d'une base de données via ADO. Il est supposé que l'ADO connexion a été établie et que les routines utilitaires sont fournis dans la classe d'exécuter des commandes SQL et gérer les données reçues. Dans cette mise en descendant les classes sont nécessaires pour remplacer la méthode de Chargement, et aussi pour fournir une nouvelle Insertion et mise à Jour de la mise en œuvre. Il est assez facile de voir que ces trois méthodes devraient générer des code SQL et mise à jour de l'objet dans le jeu de résultats (ou vice versa). Avec un peu plus d'effort, il est possible de placer plus de travail dans le générique TADO_DMObject classe elle-même, imposant une plus rigide de l'interface sur les classes descendantes qui nécessite moins de mise en œuvre. Un exemple de ceci serait l'ancêtre de la classe de générer des commandes SQL de manière dynamique, étant donné un ensemble de noms de propriétés et de valeurs.
Notre spécifiques à la classe de gestion de données objets (tels que les TCustomerDM, correspondant à TCustomer) doit avoir une connaissance approfondie sur le fonctionnement interne de la PD objet pour lequel il est responsable. En ce sens, elles peuvent être considérées comme 'ami' classes du domaine du problème de l'objet, et en Delphi cela signifie que les implémentations doivent être dans la même unité.
Ce articles du problème
Notre conception nécessite un TDMObject à fournir pour chaque TPDObject. Où et quand cette disposition pourrait-elle avoir lieu? Qu'est-ce que ce problème avec cette approche et, en analysant le modèle de la méthode des appels à notre TDMObjects, comment peut-il être contourné?
((( Liste 1 - les Données de gestion des objets et des interfaces)))
unité de Cadre
interface
type
& nbsp & nbsp TDMObject = classe
& nbsp & nbsp TPDObject = classe
& nbsp & nbsp privé
& ! & ! & ! & nbsp DMObject: TDMObject
& ! & ! & ! & nbsp FID: TObjectID
& nbsp & nbsp public
& ! & ! & ! & nbsp procédure de Charge (const ID: TObjectID)
& ! & ! & ! & nbsp procédure Enregistrer
& nbsp & nbsp fin
& nbsp & nbsp TDMObject = classe
& nbsp & nbsp public
& ! & ! & ! & nbsp procédure de Charge (PDObject: TPDObject const ID: TObjectID) virtuelle abstraite
& ! & ! & ! & nbsp fonction Save (PDObject: TPDObject): TObjectID virtuelle abstraite
& nbsp & nbsp fin
& nbsp & nbsp TADO_DMObject = classe (TDMObject)
& nbsp & nbsp privé
& ! & ! & ! & nbsp FADO: TADOExpress
& nbsp & nbsp protégé
& ! & ! & ! & nbsp // Fonctions pour aider les descendants d'interagir avec la base de données
& ! & ! & ! & nbsp procédure Execute (SQL: String)
& ! & ! & ! & nbsp propriété ADO: TADOExpress lire FADO
& ! & ! & ! & nbsp // Méthodes que les descendants doivent fournir
& ! & ! & ! & nbsp fonction Insert (const PDObject: TPDObject): TObjectID virtuelle abstraite
& ! & ! & ! & nbsp procédure de mise à Jour (const PDObject: TPDObject) virtuelle abstraite
& nbsp & nbsp public
& ! & ! & ! & nbsp fonction Save (PDObject: TPDObject): TObjectID remplacer
& nbsp & nbsp fin
application
procédure TPDObject.Load (const ID: TObjectID)
begin
& nbsp & nbsp Assert (DMObject <> nil, 'Pas de Données de Gestion d'objets disponibles')
& nbsp & nbsp DMObject.Charge (Self, ID)
fin
procédure TDMObject.Enregistrer
begin
& nbsp & nbsp Assert (DMObject <> nil, 'Pas de Données de Gestion d'objets disponibles')
& nbsp & nbsp FID := DMObject.Enregistrer ' (Auto -)
fin
fonction de TADO_DMObject.Enregistrer (PDObject: TPDObject): TObjectID
begin
& nbsp & nbsp si PDObject.ID = NotAssigned puis commencer
& ! & ! & ! & nbsp Résultat := Insert (PDObject)
& nbsp & nbsp end else begin
& ! & ! & ! & nbsp mise à Jour (PDObject)
& ! & ! & ! & nbsp Résultat := PDObject.ID
& nbsp & nbsp fin
fin
à la fin.
((( Fin Listing 1 )))
Suivant dans la série
Les objets persistants
Les objets persistants : Plusieurs milliers de conseils pour vous faciliter la vie.
l'Objet de donnees qui doivent etre stockees dans une base de donnees. Cet article vous montre comment.
Objets Persistants
Dans les deux derniers articles, nous avons introduit les objets d'entreprise et montre comment de simples relations peuvent etre representees. Les relations exprimees comme des proprietes de l'objet sont un plus formel (et neutre) de la representation des relations entre les entites de donnees qui peut etre implicite dans la conception de base de donnees, ou explicite dans le schema de base de donnees. En s'eloignant d'une centralisation de donnees en vue d'entites et de relations a un plus structuree, orientee objet, l'exposition presente de nombreux avantages, mais la plupart des langues (y compris Delphi) s'adressent uniquement pour un objet en memoire les objets de modele ont pas la persistance de l'etat de la capacite, a moins que l'un est prevu pour eux.
Il existe de nombreuses solutions de conception de cette exigence, et nous avons deja etabli que l'entreprise (probleme de domaine) les objets eux-memes ne doivent pas communiquer directement avec la base de donnees. Une conception appropriee est d'avoir un autre ensemble de classes qui existent uniquement comme un objet de l'interface de la base de donnees, et sera responsable pour le chargement et le probleme d'enregistrement de domaine de l'etat de l'objet. Notre probleme objets de domaine ne sait rien sur la façon dont leur etat est stocke sur le disque, mais seulement qu'il est une classe particuliere qui est responsable de cette operation. Les objets d'affaires permettra de faire un appel de methode sur un objet et deleguer le travail.
La premiere decision qui doit etre prise est de decider comment les objets de la carte sur un schema de base de donnees. Bien qu'un certain nombre d'objet bases de donnees existent, la plupart des entreprises ont standardise sur un SGBDR avec qui ils sont a l'aise et experimentes. La promotion d'un developpement de la changer pour une plus approche orientee objet est assez difficile, sans exiger que les generalement de gros investissements dans un tres evolue technologie de base de donnees est repliquee pour une nouvelle, inconnue. Par consequent, cet article mettra l'accent sur la cartographie des objets a base SQL SGBD, ce qui constitue la majorite de installe des systemes de developpement. Il convient, toutefois, de souligner que l'un des avantages de notre modele d'objet, c'est qu'il est totalement a l'architecture neutre et peut etre appliquee a un grand nombre de differentes topologies de base de donnees, y compris ISAM et de l'objet.
Mappage des objets de bases de donnees
Il est evident et naturel qu'il est relativement simple conceptuel de la correspondance entre un objet et un tuple (record). Par consequent, lorsque le stockage de l'etat de l'objet dans un SGBD tres commune, et pratique, la solution est de cartographier un probleme de classes du domaine a des tableaux, des objets, des documents et des proprietes des champs. Notez que parce que notre base de donnees sera le stockage de l'etat de l'objet, il doit etre une representation complete et, par consequent, il est probable qu'il y aura plus de champs dans la table de base de donnees qu'une classe possede des proprietes publiques. Dans certains cas, un bien public ne peut pas avoir un correspondant directement champ, mais le principe general est de mapper une propriete sur un champ de base de donnees de semblable fondamental de type (caractere, numerique, date, etc.)
nous allons maintenant etendre notre cadre de base des classes pour objet le soutien de la perseverance. Notre probleme objets du domaine (TPDObject) doivent permettre a d'autres classes a force de charger ou de sauvegarder leur etat. Il y a un certain nombre d'autres façons d'aborder cette situation est de forcer tous les objets de façon implicite enregistrer leur etat avant qu'ils soient detruits. Dans la pratique, les applications necessitent un meilleur degre de controle sur le moment ou l'etat de l'objet doit etre conserve et donc notre TPDObject gagnera deux nouvelles methodes publiques, de Chargement et de sauvegarde. La methode Save est sans parametre, mais notre methode de Chargement doit definir exactement quel est l'objet qui doit etre charge a partir de persistance. Dans notre cadre, tous les objets du domaine qui ont ete enregistres sont attribue un ID unique a l'interieur d'un contexte donne (ce qui pourrait etre a l'interieur des objets de la meme classe, les objets de la meme ascendance, de l'application ou de l'universel). Nous allons utiliser cet ID en tant que parametre a la methode Load de standardiser les moyens par lesquels nous etablir l'identite de l'objet. Notez que c'est toujours utilisee, meme si une classe peut avoir une solution de rechange acceptable 'cle primaire' concept. La standardisation sur un seul concept de l'identite de l'objet est utile, comme notre cadre pouvez utiliser cette coherence pour traiter notre probleme objets de domaine generique, et polymorphe de la mode. Certains peuvent se demander la presence d'une propriete publique (quoique en lecture seule) qui expose un type choisi pour des raisons de commodite pour l'adapter a l'interieur de notre cadre. Dans la pratique, l'identification des objets par ID est quelque chose qui se produit presque entierement dans le cadre du code et est rarement rencontree dans l'application de la logique elle-meme. Au sein de cette arene, les objets sont manipules a l'aide de concepts beaucoup plus familier pour les utilisateurs finaux, tels que 'l'ensemble des clients appele Smith', plutot que par les developpeurs resumes.
apres Avoir defini le public a l'interface de la methode sur notre TPDObject domaine du probleme de la classe, il nous faut maintenant envisager la mise en œuvre. En fait, c'est tres simple. Nous avons deja indique que l'objet de l'entreprise ne sait rien a propos de comment elle est stockee, mais seulement qu'il est un autre objet responsable de cette tache. Par consequent, la mise en œuvre de nos methodes de persistance sur TPDObject simplement deleguer le travail a un autre objet reference au sein d'un domaine prive. Chacun de ces appels de methode est parametre avec Soi-meme, de sorte que le delegue objet sait avec quelle instance il a a faire. En effet, lorsqu'un probleme de domaine objet est invite a enregistrer (ou de charge) lui-meme, tout simplement, il indique un autre objet de 'save me'.
Gestion des Donnees
La tache de l'economie de l'etat de l'objet a une base de donnees tombe a un ensemble de classes dans la gestion des donnees de la couche. Comme prevu, nous aurons une hierarchie de classes qui nous permet de fournir une importante base de donnees independante de la fonctionnalite. L'ensemble de nos classes responsable de la gestion des donnees de descendre d'un resume TDMObject classe. Cette classe fournit un objet de base, de la base de donnees independante de l'interface pour les operations de base de donnees. Base de donnees specifique de soutien est fourni par la creation d'un beton descendant de cette classe, qui fournit une connexion a la base de donnees de choix a l'aide de la technologie la plus appropriee, et fournit egalement certains services de base. Ces services de base sera totalement adapte aux caracteristiques specifiques de la base de donnees concernee, et sera utilise par l'application dependant de descendants personnalisee pour le traitement d'un particulier TPDObject. Cette conception n'a pas a dicter les moyens par lesquels le TDMObjects communiquer avec le moteur de base de donnees: chaque couche de base de donnees est libre de choisir le plus approprie (plus facile et plus rapide) de la technologie disponible. Cela pourrait etre ADO pour SQL Server 7, IBExpress pour Interbase, le BDE pour les fichiers Paradox, un API ou il est en effet possible de l'interface a quelque chose comme ODBC ou CORBA pour le generique de la manipulation. Ma preference est d'optimiser la connexion a l'aide d'une base de donnees dependante de la serie de composants que ceux-ci sont generalement offrent le plus de fonctionnalites et de vitesse. Notez que la selection d'une base de donnees dependant de l'API de ne pas restreindre votre application en cours d'execution avec cette base de donnees il est possible de remplacer une base de donnees dependant de la TDMObject couche pour un autre. L'interface de la TDMObject est purement a base d'objets, de sorte qu'il ne peut etre garantie qu'a condition de notre base de donnees des couches de mettre en œuvre les methodes concretes correctement, l'application fonctionnera a l'identique sans modifications.
La mise en œuvre effective de chaque base de donnees specifique de la couche depend de la base de donnees concernee, mais en general pour SQL capable de bases de donnees, il est utile de fournir un generique Executer la commande qui prend valide la commande SQL en tant que parametre. Une fois que nous avons un TDMObject descendant d'une base de donnees choisie, nous devons fournir un certain nombre de descendants de cette classe, une pour chaque TPDObject dans notre application. Ils seront personnalises pour gerer un tres combinaison specifique de l'economie d'une categorie donnee dans une base de donnees particuliere. Les details de ces classes dependent les fonctionnalites fournies par les donnees de la classe de gestion de la base de donnees particuliere, mais une fonctionnalite est essentielle: l'operation d'enregistrement doit retourner l'ID de l'objet enregistre. La raison pour cela est que, dans notre modele choisi, un TPDObject ne pas avoir une carte d'identite jusqu'a ce que la premiere fois qu'il est enregistre. Un avantage particulier de ce modele est qu'il est tres facile pour la gestion des donnees de la couche afin de detecter s'il est necessaire de generer une INSERTION ou une mise a JOUR de base de donnees de type action. En general, l'attribution de la carte d'identite pourrait etre fait par un autre objet conçu purement a cette fin, mais il est tres benefique d'optimisation qui peut etre fait, si nous nous appuyons sur notre gestion des donnees d'un objet pour en faire ce travail pour nous. N'oubliez pas que nos ID doit etre unique dans un contexte donne, si le contexte choisi est que les objets de la meme classe ont les ID unique, alors ce peut etre assimile a des enregistrements dans la table ayant les ID unique. La plupart des bases de donnees ont une certaine facilite pour la generation sequentielle ID unique pour les enregistrements inseres, et de faire de cette valeur disponible apres la mise a jour de la base de donnees. A l'aide de ce dispositif dans notre gestion des donnees de couche peut eviter la replication de l'effort pour garantir l'unicite, et dans le meilleur des cas peut enregistrer sur d'autres operations de base de donnees pour etablir le prochain ID. Si la base de donnees n'a pas un tel dispose alors d'un IDENTIFIANT interne d'allocation de regime au sein de la hierarchie de la gestion des donnees peut etre utilise.
Listing 1 montre les extensions de notre Cadre de l'unite de soutien de Charger et d'Enregistrer des operations, en collaboration avec le contour d'une classe permettant de gerer l'acces aux donnees d'une base de donnees via ADO. Il est suppose que l'ADO connexion a ete etablie et que les routines utilitaires sont fournis dans la classe d'executer des commandes SQL et gerer les donnees reçues. Dans cette mise en descendant les classes sont necessaires pour remplacer la methode de Chargement, et aussi pour fournir une nouvelle Insertion et mise a Jour de la mise en œuvre. Il est assez facile de voir que ces trois methodes devraient generer des code SQL et mise a jour de l'objet dans le jeu de resultats (ou vice versa). Avec un peu plus d'effort, il est possible de placer plus de travail dans le generique TADO_DMObject classe elle-meme, imposant une plus rigide de l'interface sur les classes descendantes qui necessite moins de mise en œuvre. Un exemple de ceci serait l'ancetre de la classe de generer des commandes SQL de maniere dynamique, etant donne un ensemble de noms de proprietes et de valeurs.
Notre specifiques a la classe de gestion de donnees objets (tels que les TCustomerDM, correspondant a TCustomer) doit avoir une connaissance approfondie sur le fonctionnement interne de la PD objet pour lequel il est responsable. En ce sens, elles peuvent etre considerees comme 'ami' classes du domaine du probleme de l'objet, et en Delphi cela signifie que les implementations doivent etre dans la meme unite.
Ce articles du probleme
Notre conception necessite un TDMObject a fournir pour chaque TPDObject. Ou et quand cette disposition pourrait-elle avoir lieu? Qu'est-ce que ce probleme avec cette approche et, en analysant le modele de la methode des appels a notre TDMObjects, comment peut-il etre contourne?
((( Liste 1 - les Donnees de gestion des objets et des interfaces)))
unite de Cadre
interface
type
& nbsp & nbsp TDMObject = classe
& nbsp & nbsp TPDObject = classe
& nbsp & nbsp prive
& ! & ! & ! & nbsp DMObject: TDMObject
& ! & ! & ! & nbsp FID: TObjectID
& nbsp & nbsp public
& ! & ! & ! & nbsp procedure de Charge (const ID: TObjectID)
& ! & ! & ! & nbsp procedure Enregistrer
& nbsp & nbsp fin
& nbsp & nbsp TDMObject = classe
& nbsp & nbsp public
& ! & ! & ! & nbsp procedure de Charge (PDObject: TPDObject const ID: TObjectID) virtuelle abstraite
& ! & ! & ! & nbsp fonction Save (PDObject: TPDObject): TObjectID virtuelle abstraite
& nbsp & nbsp fin
& nbsp & nbsp TADO_DMObject = classe (TDMObject)
& nbsp & nbsp prive
& ! & ! & ! & nbsp FADO: TADOExpress
& nbsp & nbsp protege
& ! & ! & ! & nbsp // Fonctions pour aider les descendants d'interagir avec la base de donnees
& ! & ! & ! & nbsp procedure Execute (SQL: String)
& ! & ! & ! & nbsp propriete ADO: TADOExpress lire FADO
& ! & ! & ! & nbsp // Methodes que les descendants doivent fournir
& ! & ! & ! & nbsp fonction Insert (const PDObject: TPDObject): TObjectID virtuelle abstraite
& ! & ! & ! & nbsp procedure de mise a Jour (const PDObject: TPDObject) virtuelle abstraite
& nbsp & nbsp public
& ! & ! & ! & nbsp fonction Save (PDObject: TPDObject): TObjectID remplacer
& nbsp & nbsp fin
application
procedure TPDObject.Load (const ID: TObjectID)
begin
& nbsp & nbsp Assert (DMObject <> nil, 'Pas de Donnees de Gestion d'objets disponibles')
& nbsp & nbsp DMObject.Charge (Self, ID)
fin
procedure TDMObject.Enregistrer
begin
& nbsp & nbsp Assert (DMObject <> nil, 'Pas de Donnees de Gestion d'objets disponibles')
& nbsp & nbsp FID := DMObject.Enregistrer ' (Auto -)
fin
fonction de TADO_DMObject.Enregistrer (PDObject: TPDObject): TObjectID
begin
& nbsp & nbsp si PDObject.ID = NotAssigned puis commencer
& ! & ! & ! & nbsp Resultat := Insert (PDObject)
& nbsp & nbsp end else begin
& ! & ! & ! & nbsp mise a Jour (PDObject)
& ! & ! & ! & nbsp Resultat := PDObject.ID
& nbsp & nbsp fin
fin
a la fin.
((( Fin Listing 1 )))
Suivant dans la serie
