Re: Mixing OO and DB
Date: Fri, 29 Feb 2008 13:12:49 -0500
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.
>> > 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. It's not debatable at all. It happens. In addition, when adatabase supports multiple applications, the schema may need to change for one application but the others should be insulated from that change. This is common in many enterprises.
>> >> 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. It provides a level of abstraction that reflects the problem orsolution domain more closely than either the language being used or the database schema.
>> 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. Common Lisp, for example, allows the creation of completely newlanguage constructs, including flow of control constructs, via its macro facility. This allows creation of richer DSLs than most OO languages do. A simple example is available here:
>> >> > 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. So you prefer littering your code with embedded SQL? This isn'teven an issue for the systems I work on. If a relational database is required at all, the O-R mapping is handled by a subsystem.
> By the way, what RAD tool would you recommend?
I haven't built CRUD systems in years. The last tool I used extensively was SQL*Forms. I suspect (and hope) that the state of the art has progressed from there.
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)Received on Fri Feb 29 2008 - 19:12:49 CET