Re: Mixing OO and DB

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. Plus, there are database-level remapping techniques, such as views.

> 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. It's almost like:

function addTwoNumbers(a, b) {

   return (a + b);
}

It's nonsensical busy work for one-off usages. Maybe OOP is a jobs creation program?

By the way, I forgot to mention a compromise:

function getEmployees(criteria) {

   return query(std, "select * from empl where " . criteria); }

This way you don't have to create a method for every different predicate one can dream up.

>
> > 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. I don't find that economical. The hoops you OO'ers jump thru to hide from the RDBMS is amazing.

OOP 101:

1. RDBMS are Satan.

>
> Sincerely,
>
> Patrick
>
> ------------------------------------------------------------------------
> S P Engineering, Inc. | Large scale, mission-critical, distributed OO
> | systems design and implementation.
> pjm_at_spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

-T- Received on Fri Feb 29 2008 - 02:05:51 CET