Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.

ID: 15511, An Object-Oriented Persistence Layer Design

by Robert Dawson Email: Anonymous

Philip Brown's EXE Article series and demo Delphi projects covering one approach to a layered design for business object persistence.
Download Details
FTP  download also available
CDN Login Required to Download. (You will be redirected to the login page if you click on the Download Link)
To download this, you must have registered:
A free membership

For Delphi, Version 4.0  to 5.0 6842 downloads
Copyright: All rights reserved

Size: 224,080 bytes
Updated on Fri, 19 Jan 2001 05:38:42 GMT
Originally uploaded on Fri, 19 Jan 2001 04:17:18 GMT
SHA1 Hash: 2D60254CA247EBC99AD225B19BAD0FF78E35208F
MD5 Hash: A4557649300516AF914FFADA3B50995F

    Explore the files in this upload

Philip Brown's Articles and Sample code for creating a layered, object-oriented persistence framework.

The two .ZIP archives accompanying this file were originally posted to the borland.public.attachments forum on 19 Dec 2000 by Philip Brown of Informatica Systems Ltd.

Index of EXE Articles.ZIP:
Standardising Application Builds

Adding Version Information To Applications
Last month I discussed the concept of a build, and why a standard process to produce a consistent set of deliverables was a good thing. This month we will investigate the means by which version information can be made available within an application, writing a class which can be incorporated into any new development.

Implementing Business Objects
Classes that encapsulate business rules lay the foundations of a true object oriented application.
This month's column is the first of a series in which we'll be exploring the many facets of implementing a true object oriented application. Along the way we'll take in almost every aspect of application design and challenge some of the accepted ways of writing a Delphi application. The fundamental concept behind this approach is encapsulation: to design a set of classes with well-defined interfaces (methods) that operate on properties. These concepts will pervade the entire application and will greatly affect the way in which data is stored and presented.

Simple Object Relationships
Last month we looked at how the classic Stock, Order and Customer requirement could be modelled as three separate business objects, each exposing their state through well-defined properties. Although these objects could now be used as-is (although in a very limited way - we haven't yet defined how to make their information persistent!), they lack any concept of relationships. In other words, how do we know which Customer placed a given Order, and for which StockItem?

Persistent Objects
Object data must ultimately be stored in a database. Philip Brown shows you how.
In the last couple of months we have introduced business objects and shown how simple relationships can be represented. The relationships expressed as object properties are a more formal (and neutral) representation of the relationships between data entities that can be implicit within the database design, or explicit within the database schema. Moving away from a data-centric view of entities and relationships to a more structured, object-oriented exposition has many benefits, but most languages (including Delphi) cater only for an in-memory object model; objects have no state persistence capability unless one is provided for them.

Are You Being Served?
This month Philip Brown presses the Factory pattern into service for menu operations.
This month we take a short break from the rigours of implementing business objects to deal with something that almost every application requires: a menu. Not a menu in the sense of a TMainMenu derivative, but rather some sort of front-end which shows a number of available options and requires one to be selected by the user. A typical example would be a list of options presented to the user when an application starts: they are required to select whether to launch the main application, or maybe the reporting package, general utilities or admin systems. These options are typically presented to the user in fairly crude ways, maybe a small form with a number of buttons each with a caption describing the application to be run, or a list box with a number of entries. Most often these menu-type forms are hard coded and intrinsically "know" how to launch the selected option. Such solutions share two properties: they're inflexible and unattractive. This month we use the Factory pattern (and judicious choice of visual component) to provide a better solution.

The Needs Of The Many
This month Philip Brown demonstrates one way of working with sets of business objects
This month we return to the world of a general purpose object framework and complete relationship handling by considering how to work with sets or collections of business objects. So far we have seen how to express simple 1-1 or many-1 relationships by simply exposing the related object as a property, such as Order.Customer. This is a simple and natural way to expose related objects, with the appropriate handling occurring within the accessor functions of the property, but how can we expose the other variants of relationships, namely 1-many or many-many? A simple approach, such as Customer.Order, does not serve our purpose as it implies that there is a single Order for a given Customer (which is generally not the case), and prevents access to any other Orders that might exist. What we need is syntax, and an efficient implementation, for handling a set of business objects.

Concise Custom Constructors
This month Philip Brown continues his look at implementing sets of objects
Last month I set out the broad principles behind implementing sets of objects with a problem domain oriented class to act as a container for the business objects themselves. This relied upon an extended data management class that could support navigation through a database-dependent cursor of some kind. This month concludes this investigation by providing some more implementation details and we see that once the application independent framework has been provided, the actual code required for a real system is very small.

   Latest Comments  View All Add New

Move mouse over comment to see the full text

Could not retrieve comments. Please try again later.

Server Response from: ETNACDC03