Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Bart Wakker <bhawa_at_web.de>
Date: Sun, 04 Jun 2006 11:29:17 +0200
Message-ID: <87r725jmky.fsf_at_bhawa.web.de>


"Mikito Harakiri" <mikharakiri_nospaum_at_yahoo.com> writes:

> Robert Martin wrote:
>> what's wrong with my assertion that application design should be decoupled
>> from database design.
>
> Assertion alone is worthless without solid method that supports
> it. And what method OO propellerheads suggest? OR mappers (which
> essentially are reincarnated OODBMS)? What I am supposed to learn 20
> something ad-hock mapping types instead of 6 clean relational
> operators? Or worse yet, some "pattern"?

No. Using a service oriented approach might be a way. Do not embed DBMS access code, not even if it's through an OR mapper, everywhere in your program. Using OR mapper would be just as evil when spread out everywhere in your code. Keep it out as far as possible, but at some time you must bridge the gap between OO (if that is what your application uses) and the RDBMS). To fill that gap, an OR mapper may help.

An OR mapper may help to reach this goal in another way. Suppose I have some class method foo needing some instance of class Y (which may have a lot of references to other instances). The greatest possible graph from the instance of Y to all other instances that might be reached might be very big, you might have to load gigabytes of data up front from the RDBMS. This is not practical, therefore without an OR mapper your code inside of method x may need to accesss data later as it is needed.

The OR mapper usually supports lazy loading: you fetch your data from the RDBMS before, but not all of it, just that part that you know is used in any case. Then inside your method, should the program need extra data, it doesn't have to know about how to do this, it doesn't need to know any data access API (be it direct or through some OR mapper). If just accesses/navicates to other instances as if the whole data had already been there.

Without OR mapper, you can reach the same goal but with much more effort: you must create a service for any data that may have to be loaded later (in order to separate the data access out of the core of your application logic) which may be quite cumbersome. Essentially however, all an OR mapper does is save you time and effort.

It depends on the situation and the size of your system if it is worth it to learn a new OR mapper API instead of the (simpler) low level data access API. Received on Sun Jun 04 2006 - 11:29:17 CEST

Original text of this message