Re: Mixing OO and DB

Robert Martin wrote:
> On 2008-02-28 19:05:51 -0600, topmind <topmind_at_technologist.com> said:
>
> >
> >
> > Patrick May wrote:
> >> frebe <frebe73_at_gmail.com> writes:
> >>>> We still have it, and we still use it. But we also hide it from
> >>>> the bulk of the application.
> >>>
> >>> What is the benefit with hiding SQL from the bulk of the
> >>> application?
> >>
> >> For one thing, it decouples the application code and the database
> >> schema.
> >
> > No it doesn't because the mapping has to be coded *somewhere* anyhow.
>
> The mapping is coded in source modules, of course. However, the main
> application has no source code dependencies on those modules.
> Therefore they are easy to replace with dummies or alternate
> implementations.

The only change scenarios you seem to offer is testing. Like I said before, one usually has a dummy testing database (sometimes called the "development DB") that mirrors the production database. We don't swap code, we swap DB's.

And, it's easier and more natural to type/move test data into DB's than set/gets. Mass set/gets are an ugly thing. Try using a reporting tool to print out test data that's in set/gets.

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

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.

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

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

# Backup and replication of data
# Access security
# Data computation/processing (such as aggregation and cross-

# 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

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?

>
> > OOP 101:
> >
> > 1. RDBMS are Satan.
>
> That's actually a very foolish statement that flies in the face of an
> immense body of data. There are very few OO applications out there
> that don't make heavy use of relational databases.

OO'ers see it as a necessary evil and don't have a choice because that's where all the data is. Many OO'ers want to toss RDBMS for OODBMS (commercial or roll-your-own). But companies like RDBMS. However, "OOR Mapper Systems Administrator" has become a nice job title. OOP is a jobs creation program. OO is a staff-bloater's dream. You got crap like GOF Pattern Manager, Java GUI Chief Guru, Exception Handler Taxonomy Guru, etc. etc. etc.

>
> --
> Robert C. Martin (Uncle Bob)��| email: unclebob_at_objectmentor.com
> Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com

-T- Received on Mon Mar 03 2008 - 18:24:17 CET