Re: Mixing OO and DB
Date: Fri, 29 Feb 2008 08:52:39 -0500
Message-ID: <m2ejav3m54.fsf_at_spe.com>
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?
>> 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?
VaR var = portfolio.calculateVaR();
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.
>> > 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.
Regards,
Patrick
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 - 14:52:39 CET