Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Sun, 04 Jun 2006 11:29:17 +0200
Message-ID: <87r725jmky.fsf_at_bhawa.web.de>
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