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

From: Sasa <>
Date: Thu, 01 Jun 2006 21:33:42 +0200
Message-ID: <e5nfee$kf9$>

Tony Andrews wrote:
> One could argue that to the UI programmer, the database is a "bit
> bucket" (very ugly term) of which he/she needs to know little.
> However, the UI is probably only 10-20% of the code, with 80-90% being
> the database application code - and to write this well you need to know
> your DBMS.

In my own limited experience UI is far more complex than that.

> This is a lot different from RCM's stance (as I understand it), which
> is that even the developer writing the database code - the "guts" of
> the data processing - shouldn't need to know anything about the DBMS.
> I don't agree with this.

My interpretation of RCM's stance is that one should simply decouple database from the domain model in the similar fashion as one should decouple UI from the domain model. This then makes the domain logic pure and independent of persistence as well as UI representational technology.

Obviously, in such decoupled architecture everything else is detail when seen from any part. To UI both domain and storage are irrelevant, the domain doesn't care about UI or storage, and storage doesn't care about the other two, yet the three function impeccably due to mappers between them.

Why is that good? To me primarily because it distills the domain logic (which is the core problem of the application) and reduces complexity because each part of the triad (domain, storage and UI) is fairly independent and can be developed/analyzed/maintained in the isolation. The changeability benefit is secondary, especially in case of storage (UI does change often), albeit not insignificant - one could envision scenarios where it is called for, and I have actually witnessed switch from the SQL database which had SP-s to the inferior one which didn't support SPs.

Sasa Received on Thu Jun 01 2006 - 21:33:42 CEST

Original text of this message