Re: Mixing OO and DB

From: Patrick May <>
Date: Fri, 29 Feb 2008 08:52:39 -0500
Message-ID: <>

frebe <> 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.

>> 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();

than it is to use SQL to retrieve in all of the positions associated with a portfolio and all of the time series data associated with each position, then perform a complex calculation on each set of time series data, and finally aggregate the results and perform a final calculation to get the portfolio VaR.

     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.



S P Engineering, Inc. | Large scale, mission-critical, distributed OO
                       | systems design and implementation.
  | (C++, Java, Common Lisp, Jini, middleware, SOA)
Received on Fri Feb 29 2008 - 14:52:39 CET

Original text of this message