Re: Mixing OO and DB
Date: Sat, 09 Feb 2008 09:52:18 -0500
Message-ID: <m23as26v31.fsf_at_spe.com>
frebe <frebe73_at_gmail.com> writes:
>> Even when the relational schema is embedded in a single
>> application, state changes for different reasons and as different
>> rates from behavior.
>
> Would you mind giving examples of such changes? (You can skip the
> "denormalisation for performance" example.)
Denormalization for performance of a particular application is a perfectly valid example. Thanks for mentioning it. Another reason for the different rates of change are that new behaviors can be added without the need for additional data.
>> The object model, on the other hand, is optimized to address
>> non-functional requirements (NFRs) related to the problem domain.
>
> Doesn't that indicate that OO is pretty low-level, and that the
> coupling between the logical model and the phisycal model is high?
Not at all. OO supports the creation of abstractions that represent concepts in both the problem and solution domain. Those abstractions constitute a type of domain specific language (DSL) for better expression of the solution implementation. Naturally, some languages are better at this abstraction than others.
Some of the components in an OO system will be closer to details such as data formats and network protocols while others will deal with problem and solution concepts like service lease management and value at risk calculations (to take two examples from a recent project). Techniques like dependency inversion, among many others, allow these components to be decoupled as much as possible, to allow non-disruptive modification and extension.
The terms "high level" and "low level" tend to be more pejorative than descriptive in these discussions. They make sense within a particular paradigm, but generate more heat than light across paradigms.
> Wouldn't it be better if we could separate the logical model
> handling functional requirements, and the physical model handling
> non- functional requirements?
That can be easily done with OO techniques. In fact, one of the selling points of the product suite I work with in my day job is that the application code is insulated from the deployment topology. That product is built on an OO design using OO languages.
>> > Maybe somebody may suggest me some article about mixing together
>> > DB and OOP?
>>
>> Because of the impedance mismatch, most OO systems use some
>> form of object-relational mapping.
>
> O/R mapping is not the best way of mixing together DB and OOP.
What alternative do you recommend?
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 Sat Feb 09 2008 - 15:52:18 CET