Re: Mixing OO and DB
Date: Fri, 29 Feb 2008 08:52:39 -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.
>> 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?
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.
>> > 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. pjm_at_spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)Received on Fri Feb 29 2008 - 14:52:39 CET