Mise en oeuvre de business objects

Mise en oeuvre de business objects

Mise en oeuvre de business objects : Plusieurs milliers de conseils pour vous faciliter la vie.

les Classes qui encapsulent les regles d'affaires de poser les bases d'une veritable orientee objet de la demande.
la mise en Œuvre de Business Objects
Cet article est le premier d'une serie dans laquelle nous allons explorer les nombreuses facettes de la mise en œuvre d'une veritable orientee objet application. Le long du chemin que nous allons prendre dans presque chaque aspect de la conception de l'application et de l'enjeu de la accepte façons d'ecrire une application Delphi. Le concept fondamental qui sous-tend cette approche est d'encapsulation: concevoir un ensemble de classes avec des interfaces bien definies (methodes) qui operent sur proprietes. Ces concepts s'imposer a l'ensemble de l'application et aura un impact considerable sur la façon dont les donnees sont stockees et presentees. Je voudrais lecteurs recommandes pour l'etude de Francis Glassborow C colonne bien que le Delphi modele d'objet de manque d'exhaustivite (et la complexite) de C , les concepts de la bonne conception de classe sont independants de la langue.
les Plus typiques d'applications Delphi ecrit aujourd'hui ne sont pas oriente objet. Tout simplement parce que la langue est un modele d'objet et de nombreux existantes et les nouvelles classes sont utilisees, cela ne signifie pas que l'application peut etre consideree comme veritablement OO. La reutilisation de Code a fini par l'abandon de composants tiers sur des formulaires, et les interdependances entre les formes et les unites rapidement proliferer. De perspectives d'avenir pour des applications en constante evolution des fondamentaux (comme la commutation de base de donnees ou le deplacement de 2-tier 3-tier de mise en œuvre) sont severement limitees ou tres coûteux a contempler. L'ecriture de l'application dans un vrai OO de la mode serait de faciliter, plutot que de les restreindre, ces possibilites. Toutefois, l'ecriture de ces applications necessite un changement de mentalite, accompagne par un manque initial de la productivite, que la plupart des equipes de developpement et de la reticence ou de l'incapacite a prendre en compte. Au cours de ces articles, j'espere le demontrer certains des principes fondamentaux qui aidera les developpeurs a passer a la mise en œuvre de meilleures applications. La resultante de ces systemes sera toujours plus fiable, facile a entretenir, uniforme, souple, reutilisable et fonctionnent generalement mieux qu'une application ecrite dans la norme de la mode. En particulier, les avantages de ce code clarte sont telles que pour les grandes applications, ecrit dans un veritable OO mode peut demander beaucoup moins de maintenance que la meme demande ecrite traditionnellement. Je devrais peut-etre justifier ces avantages d'un OO application plus loin: je crois que peu de ELLE defend avec quelque chose a vendre (dans ce cas, la vision de meilleures applications) devrait sortir incontestee!
L'amelioration de la fiabilite des applications OO vient du fait que les donnees et les operations sont encapsules dans les classes definies. Le compilateur lui-meme sera d'encourager la categorie correcte, de methode et de propriete par le biais de l'utilisation de la verification de type fort, et d'avoir unique plutot que de code duplique signifie que les futures modifications apportees a un seul de routine sont omnipresentes tout au long de l'application. Une consequence de l'utilisation correcte des classes, c'est que les relations entre eux sont evidents et une proportion plus grande de la code ecrit est en fait la mise en œuvre de la 'viande' de l'application, plutot que de s'inquieter de details comme la façon dont les donnees sont stockees de façon persistante. Cela rend l'application beaucoup plus facile a entretenir, un facteur encore plus simple grace a une plus grande coherence de l'ensemble. Comme nous le verrons, a l'aide de l'heritage de classe largement a la fois des augmentations de productivite et de fiabilite, mais impose egalement de la coherence. Cette coherence est evidente dans la façon dont le code est presente et dont les classes se comporter, mais aussi a la mesure de la façon dont les donnees sont stockees et comment l'interface utilisateur est presente. Comme une grande partie de la fonctionnalite est fournie dans les classes de base, il est possible de changer rapidement de leur comportement a modifier fondamentalement l'application (telles que la modification de l'interface html, plutot que sur la forme). Ces classes de base peut etre conçu de maniere a etre independante des applications, de sorte que la seconde demande ecrite de cette façon, les gains de productivite immediat boost. Un bon ensemble de classes de base peut fournir jusqu'a 50% du code dans un de taille moyenne d'application, un avantage evident a partir d'un temps, de coût et de fiabilite permanent. Il est raisonnable de mettre en evidence que la decision de passer a la 'vraie' OO developpement est non-trivial et ne doit etre effectuee pour la premiere fois a l'experience de l'aide, ou pour un projet de petite taille sans les demandes urgentes. Il convient egalement de souligner qu'un OO solution ne dicte pas les autres classes qui doivent (ou ne doivent pas) etre utilisee dans l'application. Si une entreprise a mis au point leurs propres composants visuels, utilise ceux d'un tiers, ou a standardise sur une plateforme de base de donnees alors il n'ya aucune raison pourquoi il ne peut pas etre utilise (avec une exception notable). L'elaboration d'un OO application est sur le point de l'application d'un ensemble coherent de modeles de conception plutot que de dicter ce que les composants doivent etre utilises.
Axes classes
La premiere etape dans la conception de tout orientee objet application est la reflexion sur les classes qui vont etre necessaires. C'est absolument fondamental, comme avec toute autre technique d'elaboration, de se tromper a un stade precoce sera coûteux a corriger. Dans la conception de nos classes, nous devrions tendre pour un couplage faible et une forte cohesion - les classes doivent etre aussi independants que possible des autres classes, mais devrait etre possible pour etre combines de maniere puissante. Une façon d'y parvenir consiste a classer les ensembles de classes par les roles qu'ils ont a l'interieur de l'application. Selection judicieuse de ces roles s'entraîner dans la cohesion d'un ensemble de classes.
Il y a une regle fondamentale qui revient tout au long de la classe de conception d'un role: la forte separation des classes responsable de la presentation, de l'application et de la persistance. La presentation peut etre generalement satisfaits que l'interface utilisateur, et de la persistance, comme tout ce qui stocke les donnees (generalement dans une base de donnees). Bien que ce soit la meme separation comme il en existe pour les 3 niveaux de developpement, il convient de noter que c'est un modele conceptuel de separation qui peut etre mis en œuvre dans de nombreuses façons: comme une seule application monolithique, le chemin a travers une architecture distribuee multi-niveaux du systeme. L'ensemble des classes qui constituent la logique d'application sont celles qui font le travail difficile de repondre a l'utilisateur de stimuli pour manipuler et traiter des donnees. Un sous-ensemble de classes a l'interieur de cette couche est identifie comme representant le monde reel des entites qui sera modelise par le systeme. Ceux-ci sont tres souvent etiquetes comme des 'affaires' ou 'probleme de domaine de' des classes. Ils constituent une partie essentielle de tout OO systeme, comme la plupart des autres classes seront les soutenir d'une maniere ou d'une autre, et ils forment l'objet de toutes les developpeur de participation.
Identifier le business objects pour une application donnee est generalement instinctive avec l'experience, bien qu'il y a toute une science (ou est-ce de l'art?) derriere le processus. La beaute de OO comparaison avec les techniques traditionnelles telles que SSADM, c'est que le processus d'analyse et de conception qui ont evolue de maintenir les memes entites dans l'ensemble: il est possible de voir une representation de chaque objet de l'entreprise tout au long de OOA (analyse), INONDATIONS (conception) et, eventuellement, la mise en œuvre elle-meme (POO). Nous allons explorer quelques-unes des techniques pour identifier les objets metier a l'avenir colonnes. Pour le moment, nous supposons que ces processus ont ete effectuees.
La communication entre les classes qui existent dans les differentes couches (presentation, application, persistance) est bien definie et doivent etre respectees absolument. Ceci est illustre dans la Figure 1, et les fleches indiquent qu'une classe en une seule couche pour faire des appels de methode dans une autre classe. Ce diagramme montre que la couche de presentation (l'interface utilisateur) peut manipuler la couche d'application ou d'autres classes a l'interieur de l'interface utilisateur, et que la couche d'application (business objects) peut manipuler lui-meme et de faire des appels dans la couche de persistance, qui ne peut repondre aux demandes de la couche application.
objets

la preuve que les objets peuvent etre mis en œuvre, nous allons etre a la suite d'une travaille par exemple avec un petit jeu de classes d'exposer les Actions classiques, les Clients et les commandes entites (societe offre un certain nombre d'articles en stock a la vente, qui peut etre achete (en ordonnee) par les clients). Notre (trivial) l'analyse a confirme que, initialement, nous exigerons que les trois objets pour representer chacune de ces entites. Dans notre application Delphi nous avons trois classes: TStockItem, TCustomer et TOrder. Le Listing 1 presente une synthese interface publique pour ces classes. Il convient de noter que tous les attributs de la classe sont exposees en tant que proprietes: c'est simplement de la bonne conception de classe et facilite le controle sur l'acces aux proprietes (si necessaire). Il convient egalement de noter que les proprietes sont exposes dans la publication de l'article de la classe (pour des raisons que nous allons discuter dans le futur), et qu'ils sont pleinement qualifies avec des valeurs par defaut le cas echeant. Bien que cette propriete qualificatif est apparemment utilise lors de la diffusion de composants, il est utile d'indiquer la valeur initiale de chaque propriete et a l'aide du code a l'auto-descriptif.
quelque Chose qui est fondamental pour l'entreprise (probleme de domaine) des objets, c'est qu'ils ne peuvent avoir aucune connaissance de la façon dont ils sont stockes de façon persistante. Ils ne savent pas comment elles sont stockees dans des tables de base de donnees, en fait, ils peuvent faire absolument aucune des hypotheses au sujet de stockage que ce soit. Un objet metier est un tres concentre classe qui expose seulement approprie proprietes et les methodes necessaires pour les manipuler. Lors de la conception de l'interface publique de la classe de la concession ne doit etre faite que pour les types de proprietes persistantes (base de donnees) de stockage. Vous devez toujours selectionner le type le plus approprie pour les biens en cause, independamment de si oui ou non le but de la base de donnees prend en charge nativement. Un bon exemple est un ensemble de la propriete: quelques bases de donnees support fixe directement, mais si cela est une façon naturelle d'exposer une propriete d'un objet metier, alors il devrait etre choisie de preference a une autre representation (peut-etre un certain nombre de valeurs Booleennes). Un autre exemple est d'exposer quelque chose comme une adresse comme un TStringList. Il n'est pas le role de l'entreprise objet de prejudice c'est l'interface en faveur de stockage de base de donnees: c'est la tache de la couche de persistance.
Notre premier cadre
Nous avons identifie et mis en œuvre trois objets de base de depart pour notre application. Ces trois objets partagent un meme role: representer le monde reel des entites d'une certaine façon. Par consequent, nous nous attendons a avoir des proprietes similaires et, par consequent, une hierarchie de classes est approprie. Nous allons donner a chacun de ces objets d'un ancetre commun, appele TPDObject (pour le Probleme de Domaine de l'objet). Cette TPDObject classe sera etendu au fil du temps comme nous l'avons introduit des methodes et proprietes de nos classes. Il convient de noter que TPDObject ne contient pas (et ne le sera jamais) toute demande specifique des elements. Comme une application independante de construction, il doit etre place dans une unite separee et constitue la base d'un cadre: un ensemble de classes qui peut etre re-utilise dans de nombreuses applications. Au fil du temps notre cadre permettra d'elargir considerablement d'offrir de nombreuses classes de base qui fournissent d'importants independante des applications fonctionnalite, pret a etre specialises pour des systemes specifiques. Notre TStockItem, TCustomer et TOrder classes sont des exemples de versions specialisees de notre generique TPDObject. Un examen plus approfondi de Listing 1 montre que, en fait, nos trois du domaine du probleme chacune des classes est descendu d'une autre classe, TMyAppPDObject, lui-meme un descendant de TPDObject. Bien que la mise en œuvre de TMyAppPDObject est vide, c'est un autre bon exemple de conception de classe de sorte que, si nous voulons offrir a n'importe quelle application-elements specifiques de tous nos problemes domaine des objets d'une classe dans notre hierarchie.
Listing 2 presente notre embryonnaires Cadre de l'unite. Au moment ou le TPDObject classe fournit seulement une propriete en lecture seule, appele ID, qui est de type TObjectID. Cette propriete est utilisee pour donner aux eleves le concept de l'identite: nous allons definir deux instances representant le meme objet, si elles sont de meme type et ont la meme valeur d'ID. Cela a ete deliberement definie comme son propre type de contenu de sorte qu'il n'est pas directement affectation compatible avec d'autres types scalaires. Le choix du type de TObjectID est arbitraire: j'ai choisi cet exemple pour en faire un type Entier, mais il est un cas a faire sa propre classe. Bien que plus 'pure' de la demarche, j'ai decide de contre ce, sur la base que notre probleme objets de domaine sera construit (et detruit) plusieurs milliers de fois au cours d'une demande et nous pouvons eviter la surcharge de la construction et de detruire les extra TObjectID classe (mon puriste argument en faveur de cette mise en œuvre est que de la separer TObjectID classe a ete integre dans le TPDObject classe comme un objet compose). Il ya un couple de methodes supplementaires dans cette unite a convertir notre identite de l'objet de type a une representation de chaîne, et une constante pour la premiere 'n'a pas d'identite' de la valeur.
Il y a un certain nombre d'ecoles de pensee sur l'identite de l'objet, on dit que tous les objets de gestion devrait etre alloue une identite lorsqu'il est construit et que l'identite doit etre unique au sein d'une application (ou meme a l'echelle mondiale que dans un GUID). Dans la pratique, il est important seulement pour etre en mesure de faire la distinction entre deux objets dans un contexte donne, et de garder ce simple a evidentes de performances et de stockage des benefices, bien que vous ne sera certainement pas me trouver plaidant contre un choix de plus en plus complexes, de type dans des circonstances appropriees.
Une question d'ethique
afin de mettre en evidence certains des problemes de conception et de mise en œuvre des decisions prises lors de la conception d'un cadre, je vais parfois de poser des questions et inviter les lecteurs a s'interroger sur les raisons qui le justifient. Au debut de la colonne j'ai fait allusion a une exception notable a la declaration d'une vraie OO conception ne pas interdire l'utilisation de certaines classes. Qu'est-ce que l'exception a cette declaration (indice: la reponse se trouve dans la Figure 1).
& nbsp ((( Listing 1 - Une demande specifique du Domaine du Probleme de l'unite (abregee) )))
unite de ProblemDomain
interface

& nbsp & nbsp Cadre
type
& nbsp & nbsp TMyAppPDObject = classe (TPDObject)
& nbsp & nbsp fin
& nbsp & nbsp TStockItem = classe (TMyAppPDObject)
& nbsp & nbsp publie
& ! & ! & ! & nbsp Nom de la propriete: String
& ! & ! & ! & nbsp propriete QuantityInStock: le Cardinal defaut 0
& ! & ! & ! & nbsp propriete TradePrice: Devise:
& ! & ! & ! & nbsp propriete RetailPrice: Devise:
& nbsp & nbsp fin
& nbsp & nbsp TCustomer = classe (TMyAppPDObject) ...
& nbsp & nbsp TOrder = classe (TMyAppPDObject) ...
application
a la fin.
((( Fin Listing 1 )))
((( Listing 2 - Une application-Cadre independant de l'unite )))
unite de Cadre
interface
const
& nbsp & nbsp NotAssigned = 0
type
& nbsp & nbsp TObjectID = type Integer
& nbsp & nbsp TPDObject = classe
& nbsp & nbsp prive
& ! & ! & ! & nbsp FID: TObjectID
& nbsp & nbsp public
& ! & ! & ! & nbsp ID de propriete: TObjectID lire FID defaut NotAssigned
& nbsp & nbsp fin
fonction de StrToID (Valeur: String): TObjectID
fonction de IDToStr (Valeur: TObjectID): String
application
...
a la fin.
((( Fin de Liste 2 )))
((( Figure 1 - Classe interaction overview )))
((( Fin Figure 1 )))
Suivant dans la serie