Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

phlip wrote:
> Bob Badour wrote:
>
> >> An application should have its SQL statements in only a few modules, and
> >> all others should be SQL-free.
> >>
> >> Note in my statement, you can replace SQL with GUI, XML, ORB, etc, to
> >> generally the same effect. The point of modules is to isolate and
> >> encapsulate.
> >>
> >> Is that so hard?
> >
> > Define: few
>
> Encapsulation is hierarchical. The longer the conceptual distance between
> any two points in a program, the narrower their communication should be,
> if any.
>
> So the few modules that have SQL in them should have wider communication
> with each other than with others. Sometimes we call that a "Layer".
>
> Define: wider, longer, narrower, sometimes, etc. Answer: When you don't
> mix SQL in with your GUI, XML, ORB, and other what-not modules.
>
> The alternative is like Visual Basic kiddie-kode, with multiple rampant
> SQL statements inside every button event handler. That's bad, so don't do
> that!

I've worked with code where the SQL was "encapsulated" in a seperate area. It was PAIN in the Arse. Many modifications required not only visiting two different spots (the app and SQL area), but also changing the interface between them. Back-and-forth, back-and-forth, etc.

The back-and-forth was a here-and-now cost. The "problems" that seperationists are protecting against, such as changing DB vendor, are usually remote, distant, and relatively low probability.

Time discounting works not only on money, but also human effort. I don't think SQL separation would pass a good cost-benefit analysis.

Grouping by operation/function/task is a generally good thing. It simplifies most maintanence, which tends to be task-specific. I agree there are times when seperation makes *some* tasks easier, but not enough to justify the back-and-forth effort described.

(In the future I hope we can group by both at the same time by indicating with meta-tags or relational-oriented app-code managers where the SQL starts and stops, etc. Thus we may be able to have our cake and eat it too. "Separation" and "grouping" are merely a viewpoint rather than something that we have to hard-wire into one-dimensional text. Until then, task-togetherness is the lessor of two evils.)

>
> Define: bad

Back-and-forth == Bad

>
> :-(
>
> --
> Phlip

-T- Received on Sat Jun 03 2006 - 01:50:04 CEST