Re: Mixing OO and DB

From: topmind <>
Date: Thu, 28 Feb 2008 11:27:55 -0800 (PST)
Message-ID: <>

Bob Badour wrote:
> topmind wrote:
> >
> > Robert Martin wrote:
> >
> >>On 2008-02-26 15:28:43 -0600, topmind <> said:
> >>
> >>>>I know. And yet it's not a big stretch to different kinds of
> >>>>databases. If the application uses a simple API to access it's data,
> >>>>then that API can be seperated from the application by a polymorphic
> >>>>interface, and dummy databases of a different kind can be substituted
> >>>>in.
> >>>
> >>>A "simple" API is going to replace a sophisticated and powerful query
> >>>language? I don't think so.
> >>
> >>Don't be silly. Of course it can. That's what software is all about!
> >
> > doMagic(thinAir);
> >
> > ;-)
> >
> >
> >>One of the roles of good software design is to hide complexity. We
> >>take somethign complex, like a robust query languqage, or a tricky IO
> >>driver, or a fancy third party API, and we hide it behind a simple
> >>interface that is specific to our application.
> >>
> >>In effect we are creating a domain specific language at the high levels
> >>of our application. That DSL is composed of functions that hide the
> >>complexity of what lay beneath.
> >>
> >>So, for instance, if we must fetch an employee record frequently in
> >>various parts of our application it is better to use a function like
> >>this:
> >>
> >> Employee e = Employee.find("Bob"):
> What a fucking moron! He is too stupid to realize that "record at a
> time" processing is low-level compared to set at a time processing. The
> mind boggles. It really boggles.

I don't think that's what he intended, but one cannot tell what happens if there is more than one employee from the code alone. But apparently some frameworks will load entire objects *and* their components (such as paychecks) even if you only need access to parts of them, unless you use goofy tricks such as "lazy object loading", etc., which can get tricky.

In procedural/relational programming you generally get what you need and *only* what you need from the database. The granularity is what you want it to be. In OOP, the granularity is "object", which is sometimes bigger or smaller (such as joins) than what you want. This gets back to the artificially-tight mapping between verbs and domain nouns assumed by most OO. Robert insisted that he didn't abide by such a tight coupling, but in his own example it appears as if he's guilty of it.

I look forward to his explanation.

> [snip]

-T- Received on Thu Feb 28 2008 - 20:27:55 CET

Original text of this message