Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 01 Jun 2006 19:45:40 GMT
Message-ID: <EtHfg.16133$A26.374329@ursa-nb00s0.nbnet.nb.ca>


Sasa wrote:

> 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.

This 'domain logic' to which you refer. What does it do that is not entering, manipulating, reporting or deriving data? Of that which remains, what does not interface with the external world through some device or another? Received on Thu Jun 01 2006 - 14:45:40 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US