Travailler avec des ensembles de business objects

Travailler avec des ensembles de business objects

Travailler avec des ensembles de business objects : Plusieurs milliers de conseils pour vous faciliter la vie.

Dans cet article, je viens de le demontrer une façon de travailler avec des ensembles de business objects
Les Besoins De Beaucoup
Dans cet article, nous revenons au monde d'un usage general, cadre d'objet et la relation de manutention en considerant la façon de travailler avec des ensembles ou des collections d'objets metier. Jusqu'a present, nous avons vu comment l'exprimer de simples 1-1 ou plusieurs-1 relations simplement en exposant l'objet d'une propriete, comme l'Ordre.Client. C'est un moyen simple et naturel pour exposer les objets lies, avec la manipulation appropriee survenant dans les fonctions d'accesseur de la propriete, mais comment peut-on exposer les autres variantes de relations, a savoir la 1-plusieurs ou plusieurs-plusieurs? Une approche simple, comme Client.Afin, de ne pas servir a nos fins, car elle implique qu'il existe une unique Commande pour un Client donne (qui n'est generalement pas le cas), et interdit l'acces a toute les autres Commandes qui peuvent exister. Ce dont nous avons besoin est de la syntaxe, et une mise en œuvre efficace, pour le traitement d'un ensemble d'objets metier.
Si nous pensons a ce sujet dans une maniere differente, puis nous avons besoin d'un objectif general de moyens de manutention tels un ensemble d'objets. Dans la pratique, ainsi qu'une petite collection d'objets (tels que la liste des Commandes pour un Client donne, generalement compose d'au plus quelques centaines d'entrees) nous aimerions egalement a l'appui de grandes collections d'objets, tels que la liste de tous les articles en Stock. Comme nous sommes dans un objet du monde orientee, la conclusion logique est que nous avons besoin d'une nouvelle classe qui expose un ensemble d'objets metier. Laissez-nous appeler cette classe TPDList (une liste de Probleme objets du Domaine) pour aller avec nos TPDObject classe. Le nom est arbitraire et certains peuvent penser que celui-ci implique une mise en oeuvre particuliere. Malheureusement alternatives telles que 'set' et 'collection' deja des consequences au sein de l'Delphi monde.
sucre Syntaxique
d'Un point de vue syntaxique agreable et naturelle façon de traiter un ensemble d'objets serait de les exposer a l'aide de une sorte de tableau, comme dans le Listing 1. Une telle definition de la classe nous permettant d'acceder aux objets a l'aide des constructions dans notre code Client.Les commandes[], ce qui est tres familier. Cependant, il y a deux principaux inconvenients de cette approche: elle implique que nous savons combien d'objets sont dans la liste, et qu'ils sont tous disponibles en acces aleatoire type de mode. La seule façon de s'assurer que ces conditions prealables sont remplies, c'est pour bien remplir la liste, ou au moins remplir entierement une liste interne de l'ID de l'objet et de la charge de chaque objet individuellement en tant qu'il est accessible. L'inconvenient de la premiere approche est la consommation excessive de memoire et, eventuellement, un retard notable, tandis que le nombre d'objets instancies, et l'inconvenient de la deuxieme approche est l'inefficacite de la delivrance d'un enregistrement de la charge pour chaque objet accessible (pas a pas dans un ensemble de 100 objets aurait besoin de 100 requetes de base de donnees pour etre publie).
Donc, en depit de la syntaxe des avantages de la matrice de l'approche n'est pas optimale pour le cas general, meme si bien sûr, un cadre de travail pourrait etre etendu pour prendre en charge deux (ou plus) manieres differentes de traiter des ensembles d'objets, un pour les petits et un pour les grands. Personnellement, je suis un grand fan de la coherence et prefererait qu'une seule syntaxe pour travailler avec des ensembles d'objets. Comme nous le verrons ulterieurement dans une autre colonne, cela ne nous empeche pas d'avoir un certain nombre d'implementations de cette syntaxe, a l'ecoute pour des circonstances differentes.
Au niveau le plus fondamental de nos objets vont etre remplie a partir de mecanisme de stockage persistant, generalement une base de donnees. La plupart des donnees ces jours-ci est accessible par le biais d'une requete (SQL) et si l'on considere les proprietes de ces elements, ils sont generalement en mesure de nous fournir de la 'prochaine' disque conceptuel, et de determiner si la liste est epuisee. Generalement des informations telles que le nombre d'enregistrements dans la liste, ou a acces aleatoire, n'est pas disponible. Notre cadre de travail devrait etre conçu avec des performances et de la demande les besoins en ressources dans l'esprit, de sorte que suggere par l'interface de notre TPDList est indique dans le Listing 2. Cela nous donne une Premiere methode (re-initialisation de la liste de revenir au debut), a Cote (acces a l'objet suivant dans la liste) et une IsLast de propriete (en indiquant lorsque la liste est epuisee). Le 'courant' de l'objet dans la liste est disponible via la consequence d'une propriete nommee. Cette interface peut sembler inutilement simple ou sont les methodes pour soutenir l'arriere de navigation? L'experience montre que l'inverse de la navigation a travers une liste est tres rarement necessaire, et ou il est, peut etre facilement accompli par d'autres constructions. Pour le moment, nous allons maintenir notre liste de la classe de gestion simple.
Comment est cette classe a etre mis en œuvre? Comme avant, notre probleme de domaine (business object) couche devrait avoir aucune notion de la façon dont les donnees sont stockees ou geres. Notre TPDList gere une collection d'objets d'entreprise et ne peut donc pas etre une mince wrapper autour de quelque chose comme base de donnees specifique a une requete de base de donnees. Au lieu de cela, nous allons creer une autre classe pour gerer le support des bases de donnees pour les listes d'objets, et de fournir un objet de base de donnees independant de l'interface entre notre TPDList et de cette classe. De cette façon, nous avons garde la stricte separation entre la couche metier et la gestion des donnees de la couche, ce qui nous permet une totale flexibilite dans la maniere dont ce dernier est gere.
Edulcorants la pilule
De la meme maniere que notre TPDObject avait un TDMObject de gestion des donnees corollaire, il peut sembler que nous TPDList devrait avoir un TDMList equivalent. Dans la pratique, il y a une grande quantite de points communs entre les deux donnees de gestion des classes et ils peuvent etre regroupes en une seule classe. Il peut sembler logique d'avoir une hierarchie de classes qui partagent un ancetre commun, de fonctionnalite et de descendants de gerer les cas uniques et des listes, mais cela impose un code d'ecriture de surcharge quand il s'agit de la mise en œuvre de notre application, avec peu d'avantages. Nous allons donc etendre notre TDMObject a l'appui de la liste des operations, ainsi que l'existence d'instance unique de Chargement et de sauvegarde.

Chaque TPDList va donc etre proprietaires de TDMObject qui est responsable uniquement pour la gestion des acces aux donnees de la liste d'objets. Le 'courant' TPDObject exposes par la liste va imiter le 'courant' enregistrement dans la base de donnees du curseur. Nous avons besoin d'un unique (et prive) gestion des donnees de l'objet pour chaque TPDList parce qu'il a besoin pour maintenir l'etat (les informations de requete, curseur en cours d'enregistrement et ainsi de suite). En revanche, du domaine du probleme des objets de la meme classe peuvent partager un seul de gestion de donnees objet, car le Charger et Enregistrer des methodes sont des operations passives.
Notre TDMObject peut maintenant etre etendu pour prendre en charge les operations necessaires. Il aura FirstRecord et NextRecord methodes (pour indiquer qu'il est base sur des enregistrements de la nature), et un IsLastRecord propriete pour indiquer lorsque le curseur est epuise (ce curseur sera prive pour la gestion des donnees de l'objet et articulee autour d'une base de donnees dependant de mecanisme de requete). Les methodes dans notre TPDList sera tout simplement delegue de travail hors de gerer les donnees de l'objet, l'appel de ces methodes appelees. Le TPDList demande au prive de la gestion des donnees objet de fournir une instancie probleme objet de domaine que le client de l'application des mesures a travers elle. Le code pour remplir cet objet de la requete curseur doit etre partage avec qui, pour l'alimentation d'un seul objet a la Charge de la routine.
Nous avons maintenant une classe qui nous permet de naviguer a travers un ensemble de probleme objets du domaine, et nous avons etendu nos donnees de gestion de classe pour prendre en charge ces operations. Ce que nous n'avons pas encore fait est de definir comment les differents ensembles d'objets doivent etre definis. Apres tout, il ya beaucoup de differents types d'ensembles d'objets de notre application peut necessiter nous pourrions avoir besoin de l'ensemble des clients qui ont commande un particulier element de stock, nous pourrions avoir besoin de la clientele appele 'SMITH' ou nous pourrions avoir besoin de l'ensemble de tous les clients (a des fins de reporting). Un moyen evident de definir ces differents jeux que nous avons peut-etre besoin est pour definir des constructeurs. Le Listing 3 montre l'interface publique pour un exemple TCustomerList qui gere un ensemble de clients. Vous verrez egalement qu'il expose une propriete du Client cela renvoie simplement la CurrentObject transtypage statique a un TCustomer (nous savons et nous nous attendons a ce que tous les objets de la liste pour etre de ce type c'est donc un fonctionnement sûr et evite de placer le transtypage a l'interieur de la logique de l'application). Certains ultra-puriste OO defenseurs pourrait pretendre que, plutot que d'utiliser des constructeurs une hierarchie de classe doit etre cree, avec une nouvelle classe pour chaque type de liste necessaires. Personnellement, je ne peut voir le peu d'interet de cette approche a moins que l'ensemble des objets necessite une certaine particulierement implique manipulation qui doit rester prive pour une liste specifique de mise en œuvre, et cette approche a l'inconvenient de necessiter une quantite considerable de code a ecrire et, en consequence, de classe de la proliferation.
Nous pouvons maintenant traiter avec des listes de clients simplement par la construction d'une TCustomerList dans la maniere la plus appropriee. Notre code de l'application peut ressembler a quelque chose comme ceci:
var
& nbsp & nbsp CustomerList: TCustomerList
begin
& nbsp & nbsp CustomerList := TCustomerList.CreateByName ('DUPONT')
& nbsp & nbsp essayer
& ! & ! & ! & nbsp CustomerList.Premiere
& ! & ! & ! & nbsp alors que pas CustomerList.IsLast do begin
& ! & ! & ! & ! & ! & nbsp // Faire quelque chose avec CustomerList.Client de l'objet
& ! & ! & ! & ! & ! & nbsp CustomerList.Suivant
& ! & ! & ! & nbsp fin
& nbsp & nbsp enfin
& ! & ! & ! & nbsp CustomerList.Gratuit
& nbsp & nbsp fin
fin
d'Avoir ce genre de logique au sein de l'application est beaucoup plus claire que l'equivalent moyens proceduraux de la construction de la base de donnees des requetes specifiques et l'utilisation de champs directement. En particulier, nous avons encapsule tous ces details a l'interieur de nos donnees de gestion de la classe et du present code, la centralisation permet le luxe de savoir que les opportunites pour le referencement d'un tableau non valide ou nom de champ sont considerablement reduits.
jusqu'a present, nous n'avons pas specifie de la mise en œuvre effective de la coutume constructeurs dans notre gestion de la liste d'objets. Comme l'a deja note, ces classes s'asseoir resolument dans notre application, la logique d'entreprise et, par consequent, doit etre entierement de la base de donnees independante. Plus precisement, ces constructeurs ne peuvent pas etre implique dans la construction de requetes SQL ou autre. Ces details sont de la competence du role de nos donnees de gestion de la classe, et donc le correspondant TDMObject pour chaque classe d'acquerir personnalise constructeurs, chacun correspondant exactement au nom et les parametres de ceux de la TPDList objet pour lequel il est responsable. Le mois prochain nous allons finir cette manipulation en regardant quelques-uns des details de mise en œuvre, et en montrant comment les ameliorations de notre conception de classe, et la puissance de polymorphisme, conduit a de tres reduite de l'ecriture de code pour notre clientele des classes de l'application.
Cet article est question
Etre capable de gerer des ensembles d'objets, c'est le bloc de construction pour la manipulation des relations d'objet. Comment pouvons-nous les utiliser a l'appui 1-nombre de relations comme Client.Les commandes, et nous pouvons aider ces constructions generiquement de la meme maniere que nous avons fait pour le 1-1 et beaucoup d'-1 relations?
((( Listing 1 - Matrice a base de TPDList interface)))
type
& nbsp & nbsp TPDList = classe
& nbsp & nbsp public
& ! & ! & ! & nbsp propriete ObjectAtIndex[Index: Integer]: TPDObject par defaut
& ! & ! & ! & nbsp propriete Count: Integer
& nbsp & nbsp fin
((( Fin Listing 1 )))
((( Listing 2 - Navigation TPDList interface)))
type
& nbsp & nbsp TPDList = classe
& nbsp & nbsp public
& ! & ! & ! & nbsp procedure de Premiere
& ! & ! & ! & nbsp procedure Suivante
& ! & ! & ! & nbsp propriete CurrentObject: TPDObject
& ! & ! & ! & nbsp propriete IsLast: Boolean
& nbsp & nbsp fin
((( Fin de Liste 2 )))
((( Listing 3 - Exemple TCustomerList interface publique)))
type
& nbsp & nbsp TCustomerList = classe (TPDList)
& nbsp & nbsp prive
& ! & ! & ! & nbsp // Resultat := TCustomer (CurrentObject)
& ! & ! & ! & nbsp fonction GetCustomer: TCustomer
& nbsp & nbsp public
& ! & ! & ! & nbsp constructeur CreateAll
& ! & ! & ! & nbsp constructeur CreateByName (const Nom: String)
& ! & ! & ! & nbsp constructeur CreateByStockOrder (Item: TStockItem)
& ! & ! & ! & nbsp propriete de la Clientele: TCustomer lire GetCustomer
& nbsp & nbsp fin
((( Fin Listing 3 )))
Suivant dans la serie