Data Controls and OOP

[Dooda]

How can data controls be used with OO applications?

If you have a Customer object through which all access to Customer's attributes is routed, how can a data grid be used to list all customer names? If the data table is linked to the grid, independence of the logic code from the data structure is lost. To avoid that, retrieving the names via the Customer object will require looping till EOF is detected (somehow).

Similar issues occur with updates from edit controls, replacing built-in functions with calls to the Customer object, which then has to include lengthy SQL update statements.

The benefits of OO apps appear to be discounted by the loss of Delphi's data control facilities. Or am I missing something?

 

[roo0047]

In my experience (thru D7) table are linked to the grid and edit controls by TDataSource object. Umless you question is more version specific, I don't understand what you are asking.

Roo
Delphi Rules!

 

[Dooda]

I gather that to enable "rules" of whatever type that cannot be embedded in a common point, such as database triggers, they are built into the object's methods. This overcomes the problem of forgetting to put the "rule" in any place where it's relevant and having to ensure it's tested in each place (rather than just once).

A simple example would be the membership ID for a club application I wrote. Its format was ANNN so a standard numeric check was inappropriate and specific code had to be written wherever a new one was created. That code should occur once - in the create method of the relvant object.

Strictly it seems the same should be true of data retrieved, so that if the storage or retrieval method change then code in only one place is altered.

So the question is, if you put all the data access behind methods in OO coding, how can you utilise the easy methods that Delphi data controls normally allow?

 

[roo0047]

Although I don't know what ANNN means, my method of enforcing db rules is to put them as functions and procedures in a TDataModule along with all my table definitions, queries, connections, and anything else I need to setup my database. These functions and procedures are then triggered by the events associated with each of the components within the datamodule.

As a personal rule, I avoid utilizing events generated by edit controls in db forms, which keeps all db rules centralized.

For example, we have table "Logbook" where all jobs are entered which links to table "Orders". If field "PoNo" is changed in OrdersForm, when saved, Logbook.PoNo also gets updated so that when Invoice is created, it contains the corrected PoNo. This is all performed within the DataModule.

HTH

Roo
Delphi Rules!

 

[Dooda]

Interesting that no-one seems to have an answer to this situation, perhaps indicating that there is no easy solution. There arises a suspicion that if you implement full OO encapsulation (if that's what it's called) then the fall in productivity caused by the loss of data control use outweighs any OO gain.

I think you, Roo, have got what would be a workable method for OO by doing the updates centrally but not trying to centralise read access. The chances of changes affecting database reads without concomitant changes to application code are pretty well zero. It does however leave you with a gap if you want to update data grids, for example. It may be possible to use some event to divert the write method, perhaps.

Using a TDataModule did catch my eye a long while ago but I did not seem to be able to easily refer to tables in it from another unit. If there's a note you know of that gives an example I'd be very glad to hear of it.

And by the way, ANNN means one alpha and 3 numeric characters - sorry, I thought the COBOL-like notation was in general use.

Many thanks for your input on this.

 

[lespaul]

I guess I'm still not sure why you don't use the DataModule...you add it to the uses clause just like you would any other component/unit you want to access. All the data components (database, tables, queries) can be stored there, accessed, updated, modified. You can create DataSources for objects and set those to the source of DB objects.

Leslie

 

[harebrain]

>I thought the COBOL-like notation was in general use.

Well, then, it should be A999, no?

 

[Dooda]

You're right, of course. Have to admit it's over 30 years since I was employed to write COBOL and the brain is getting rusty as I am not supposed to do any coding now. (I enjoy it most but it does not pay enough.)

Must have another attempt at using a TDataModule. Might be easier now on a later version.

 

[roo0047]

TIP: When referencing db components (that are defined in a separate datamodule) in forms, first, manually add the datamodule unit name to the uses clause. When assigning DataSource to edit controls in the Object Inspector, you must reference the datamodule name AND the datasource name. Example:

Form1.DBGrid1.DataSource:= DataModule1.Table1DS;

Assuming Table1DS is a TDataSource who's DataSet is assigned to Table1.

Form1.DBGrid1.DataSource:= DataModule1.Table1; is incorrect and will not compile but is a common mistake.

Happy coding!

Roo
Delphi Rules!

 

[DjangMan]

It almost sounds like you want to introduce middleware.

http://www.components4programmers.com/index.htm

With their kbmMW you can isolate your business login in a middle layer and then write your interfaces in any way that you like. If you had to change the validation logic you could do that in the middle layer and the client layer could remain unchanged. It is above my head but I'd love to develop my applications that way.