Re: Mixing OO and DB
Date: Fri, 29 Feb 2008 08:43:44 -0800 (PST)
> >> >> 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
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