Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Tue, 13 Jun 2006 16:18:20 -0400
Message-Id: <> wrote:

>> Applications are generally independent of each other (altough they
>> often communicate indirectly through the DB).

> Unless you use reusable domain objects. Lets say we have a customer
> table, does every application has its own customer class?

If constraints and automations, or simply "biz rules" for short, are implemented in the server, you can have as many apps as you want. Great way to increase longevity of your system.

> If we change the data, lets say we add a new column, phoneno, to the
> customer table, doesn't the application need to change?

Depends on the case.

For a program where the entire "application" is table-maintenance screens, reports, labels and so forth then an added column should require zero code. The data dictionary should update the table maintenance forms for you for free.

If there are ad-hoc screens for each table because each screen has a carefully crafted public face, more like a shopping cart, then changes tend to be much more carefully considered, and that careful consideration goes into both the database and the database's public face.


>> If, on the other hand, the applications are designed to be independent
>> of the database structure, then the applications can use whatever data
>> structures are appropriate for their algorithms.

> A algorithm could must obviously know about the data structure.

Hmmm. Generally speaking only a very limited class of routines can be independent of data structure. Primary is dictionary-processing routines that can do the same sorts of things on many different tables. But of course they themselves need somehow to know the structure of the meta-data tables.

But in terms of form-follows-function, the application will always follow the structure of the data, the reverse should never be true.

Kenneth Downs
Secure Data Software, Inc.
Received on Tue Jun 13 2006 - 22:18:20 CEST

Original text of this message