Re: Mixing OO and DB
Date: Mon, 03 Mar 2008 14:40:21 -0400
Message-ID: <47cc461a$0$4030$9a566e8b_at_news.aliant.net>
topmind wrote:
>>On 2008-02-28 19:05:51 -0600, topmind <topmind_at_technologist.com> said: >> >> >>> >>>Patrick May wrote: >>> >>>>frebe <frebe73_at_gmail.com> writes:
[snip]
>>>>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) >>>DB. >> >>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