Re: Mixing OO and DB

From: Bob Badour <>
Date: Mon, 03 Mar 2008 14:40:21 -0400
Message-ID: <47cc461a$0$4030$>

topmind wrote:

> Robert Martin wrote:

>>On 2008-02-28 19:05:51 -0600, topmind <> said:
>>>Patrick May wrote:
>>>>frebe <> writes:


>>>>For another, as noted by Mr. Martin, it allows the creation
>>>>of a domain specific language that better reflects the concepts in the
>>>>problem and solution domains.
>>>But it is not "upping" the abstraction enough to justify all the
>>>method proliferation.
>>Sure it is.  find_eligible_employees is at a higher level of
>>abstraction than select * from ... and ... where ... < ... or ... ...
>>... ;

And is a much lower level of abstraction than a corresponding view: eligible_employees

For example, how does one join eligible_employees with eligible_benefits using find_eligible_employees ?

> Barely. Use a *comment* if need be. I am not going to use methods/
> routines as merely a glorified comment. Extra routines/methods creates
> clutter.

Even better, use a language like D, which allows one to spell out named predicates using the "with" keyword.

with eligible_employees = employees

      where /* eligibility criteria */
, eligible_benefits = benefits

      where /* eligibility criteria */
, bennies = eligible_employees join eligible_benefits etc.

>>The abstraction level is also "upped" because the method is decoupled
>>from it's implementation (meaning that the source code that calls the
>>method has no source code dependency on the implementation).

Frankly, that's bullshit. For example, it still has a dependency on the eligibility parameters and it has a dependency on how the source handles multiple qualifications for eligibility for a single employee. And most importantly, it depends heavily on the structure chosen to return the result.

>>>It's almost like:
>>>function addTwoNumbers(a, b) {
>>>   return (a + b);
>>No, it's more like:
>>Money netPay(Money earnings, Money deductions) {
>>  return earnings - deductions;
>>The calculation has a *meaning* or intent; and the method provides the
>>name of the intent.

> Again, use a comment if need be:
> // calc net pay
> netPay = earnings - deductions;

Or use the "with" syntax described above:

with netPay = earnings - deductions
, ...

Or use a view.

>>>>>If you have a lot of find_by_xxx methods, swapping would still be
>>>>>quite difficult.
>>>>That is true.  In my experience there isn't usually a
>>>>proliferation of such methods because traversal is done by object
>>>>reference rather than by some subset of object state.
>>>In other words, your app reinvents a (navigational) database in the
>>>app. You can query the DB less because your app becomes a (half-ass)
>>Not quite.  The app because an *application specific* DB.  That's not
>>half-assed at all.

> Existing RDBMS tools are usually sufficient. They provide these
> features almost out-of-the-box:
> # Persistence
> # Query languages or query ability (standardized collection-handling
> idioms)
> # metadata repository
> # State management
> # Multi-user contention management and concurrency (locks,
> transactions, rollbacks, etc.)
> # Backup and replication of data
> # Access security
> # Data computation/processing (such as aggregation and cross-
> referencing)
> # Data rule enforcement or validation
> # Data export and import utilities
> # Multi-language and multi-application data sharing
> # Data change and access logging
> # Automated "search path" optimization (user focuses on what, not on
> how)
> I don't want to have to reinvent all this sh8t from scratch.
> Plus, OO is navigational, and relational is superior to navigational
> in my opinion. Navigational is messy, and is the reason that RDBMS
> replaced them. How many times do we have to keep reliving the lessons
> of the 60's and 70's?

Don't eat the brown acid. The brown acid is bad. I repeat: Don't eat the brown acid. If you think you may have eaten the brown acid, go to the medical tent at the back of the concert area.

[snip] Received on Mon Mar 03 2008 - 19:40:21 CET

Original text of this message