english (en) | português (br)

PressObjects' data types have a completely different structure than the classes that are involved with TDataSet, nevertheless its possible to show some similarities and assist those that are already familiar with DBWare.

Contents 1 Object oriented data types 1.1 The business object 1.2 Business object members 1.3 Aggregations and compositions 2 Business object presentation 3 Object persistence

Object oriented data types

The business object

The biggest difference is in not using TDataSet as business object. The entity that comes closest to it is the TPressObject class. Nevertheless, with rare exceptions, a TDataSet deals with a collection of data and a cursor, whereas a TPressObject always deals with unique data. The information that TPressObject holds is, for a TDataSet, the information where a cursor might point to or the actual data.

A TDataSet descendant is used to create objects that navigate the data. That data might be a list of products recently retrieved from the database. Navigation routines allow moving the cursor between products, edit routines allow putting the information to be altered, to be saved or reverted (canceled).

A TPressObject descendant, analogous to the above example would be TProduct, is used to create an object with the proper information and not a list of information. The concept of next and previous does not exist, since a list does not exist. Since there is no list, neither would be edit mode, confirm or cancel changes.

To retrieve a list, there exists specific routines which can be consulted in the article retrieving objects. What is received is an object similar to a TStringList, with a Count property, and each index points to a TProduct class object. To change a product, just access any of its members and assign a new value. To confirm the changes (to the database), a routine is called that receives the object as a parameter. To reverse the changes done in a business object, which is equivalent to the TDataSet's Cancel, a SavePoint should be restored.

Implementation details aside, the big difference between a TDataSet and a TProduct is that the TDataSet is generic and does not know anything about the data it contains. Whereas a TProduct knows itself (since its specific to the product) and behaves according to its business rules.

A TDataSet object changes its contents when moving from record to record, therefore you are dealing with one object that changes its data. With a TPressObject you are dealing with multiple objects, one for each record in the database.

Business object members

Starting from TDataSet fields, these start to be like TPressObject.

A TDataSet descendant object is created with a set of fields, for details like a SQL statement or master-detail configurations which will be tackled ahead.

Each TDataSet field points to a type of data, the product name for instance, via a cursor. Via the cursor, it moves data in each of its fields. Since a TPressObject refers to a unique object, its members will always have the same value until the user changes it explicitly.

Aggregations and compositions

(Problem translating the first paragraph)

Another peculiarity of aggregations and compositions in PressObjects is the easiness with which the data is shared. In case two different orders have items that references the same product, only one instance of this product will be in memory, no matter which method was used to read the order or product. When this data is changed, all the MVP fields in which this data appears, whether in a grid, a combo or an edit, via a the product form, the order's item or the order, these will all be updated. The PressObjects use counted reference to certify that no object will be destroyed if its still in use, and that it will be destroyed if there is no longer any reference to it.

TPressObject descendants know themselves very well, and anything that references the object can use the data. Data that the TPressObject can contain are among others an aggregation, that substitutes the foreign key, and a composition, that substitutes a master-detail (that is not really how they relate, read Business Classes for more details that illustrates this better).

For the developer:

• associate a city to the client address is only "VClient.city := VCity;"
• add an item to an order just "VOrderItem := VOrder.Items.Add"
• save an order, all its items, all the invoices, the client has recently registered, all within a transaction and generating all the primary and foreign key for all the objects and their respective relationships, just "Session.Store(VOrder);"

Business object presentation

(to do)

Object persistence

(to do)