Re: Mixing OO and DB

From: frebe <>
Date: Fri, 29 Feb 2008 08:43:44 -0800 (PST)
Message-ID: <>

> >> >> 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.
> > And the benefit with decoupling application code and database
> > schema, is?
>      You've asked this before and it has been fully answered.  The two
> components change at different rates for different reasons, especially
> in distributed applications and when the database supports multiple
> applications.

The only answer so far is about "denormailzation for perforance", which is a very debatable argument.

> >> 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.
> > What created language are you talking about, the API?
>      I'm referring to the classes and associated methods that reflect
> the problem and solution domains.  It is more understandable to
> provide an interface like:
>      VaR var = portfolio.calculateVaR();

But it is hardly a new language. In that case one could argue that a view is a language too.

>      Personally, I find it easier to create DSLs with functional
> languages that allow the creation of new, first class language
> constructs, but OO techniques can provide some value.

I agree that funcational languages are superior to OO languages, but a function library is not a language itself.

> >> > 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.
> > What does the number of find_by_xxx methods has to do with object
> > traversal? Anyway, I have seen many "OO" application, there the number
> > of find_by_xxx methods are huge and you are forced to use a
> > find_by_xxx methods that doesn't really fit, or create a new one.
>      That would indicate either bad design or the application of OO
> techniques to a simple CRUD system that would be better implemented
> with a relational RAD tool.

Yes it is indeed bad design to force every SQL statement to be wrapped inside a method. By the way, what RAD tool would you recommend?

//frebe Received on Fri Feb 29 2008 - 17:43:44 CET

Original text of this message