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

From: Phlip <>
Date: Sun, 04 Jun 2006 16:16:43 GMT
Message-ID: <LHDgg.132108$>

frebe73 wrote:

>> Any real examples would require way too much space.
> You are free to send pointers to another website if you want to.
> Unsupported claims are not very useful.

Could you state back the claim you feel is unsupported?

(I could Google, then I realized that might not align us...)

> If you have the same data stemming from different orgins, just put the
> database connection string into a configuration file. What do you mean
> with "different kind of orgin"? Like relational, network, hierachical?

Per the general thread, it means maybe data X comes from a DB, and data Y comes from a flat file, and they both come thru the same interface, so the business logic that adds value to them can't tell where each came from. Liskov Substitution Principle.

(I'm aware much business logic is indeed inside the database. Same difference; the logic should still be encapsulated.)

>> Yes, you could declare JDBC to be the universal API to hide any data
>> access, and access corba, rmi, ldap all through JDBC. The question is
>> if that is wise. It would be better to hide it behind an API that fits
>> more naturally in the environment (java in this example, so rather
>> using Interfaces).
> Corba and RMI are a protocol for inter-process communication. LDAP is a
> protocol for a hierachial directory service. They are totally different
> things. Corba and RMI may be used for communication between a client
> computer and a database server or any kind of remote service. LDAP can
> only be used there the the remote service is a hierachical
> database/directory of some kind.

If you need data, you should get it from whatever system, thru a common interface. The alternative taints business logic with runaway dependencies.

> But in this scenario the change is initated by "new business logic". If
> the the business logic change, I assume that the business layer change
> too.

Right - that's the definition of coherency.

Further, I now realize coherency does not imply adjacency. Suppose the data flow thru four modules, A->B->C->D. Now you might change A and D at the same time, for a legitimate reason. You add value to both modules. That's coherency between A and D, even though they share no interface.

> Lets say the original table looks like this:
> client(clientid, ...., domicile)
> Your change need a new table:
> client_domicile(client, domicile)
> Because there still are some kind of default domicile (the first in
> alfabetical order), the client table is not changed. Your change
> consist of adding a new table, which don't affect the old SQL
> statements at all. Unless you want to use the new 1:M relationship, you
> don't have to change to application at all.

Right. Most libraries are closed for modification and open for extension - along certain lines.

  Phlip <-- NOT a blog!!! 
Received on Sun Jun 04 2006 - 18:16:43 CEST

Original text of this message