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

From: Christian Brunschen <cb_at_festis.df.lth.se>
Date: Thu, 1 Jun 2006 11:25:29 +0000 (UTC)
Message-ID: <e5mir9$gug$1_at_news.lth.se>


In article <1149159361.846295.4330_at_g10g2000cwb.googlegroups.com>,  <frebe73_at_gmail.com> wrote:
>> Fair enough. But in that case you have at least committed to using a
>> SQL DBMS, and that it will be from one of the major players in the
>> market. That is somewhat different from RCM's position, which is (as I
>> understand it) that it should be trivial to unplug your SQL DBMS and
>> replace it by something else that doesn't even use SQL.
>
>The big questing is: Why do you want to unplug the SQL DBMS?

For a trivial example, consider an application that needs to somehow authenticate users (because different users have permission or not for different parts of the functonality of the application. The user information (name, password, etc) will have to be stored somewhere - a relational database might be an excellent place, in particular if this application is essentially a stand-alone one.

However, it might be that the application is intented to be integrated into an existing infrastructure, that has user information stored in an LDAP-accessible database; or for another example, the user information might be stored in a Unix-style flat file (a la /etc/passwd).

By separating out the logic that handles any interaction between the chosen database into separate, database-specific modules that share a common interface, the rest of the application can remain identically the same, with only the database-specific parts needing to be plugged in or out, depending on the precise environment where the application is deployed.

Best wishes,

// Christian Brunschen Received on Thu Jun 01 2006 - 13:25:29 CEST

Original text of this message