Re: Mixing OO and DB

From: frebe <frebe73_at_gmail.com>
Date: Fri, 29 Feb 2008 08:38:46 -0800 (PST)
Message-ID: <f6567393-daf7-4add-90b2-021c16034678_at_e10g2000prf.googlegroups.com>


> >>      I tried to be very clear with what I was saying.  In the large
> >> OO systems that I've worked on, there was no problem with
> >> proliferation of finder methods in practice.
>
> > In applications there problem with proliferation of finder methods
> > doesn't exists, the find methods have to be very simple, like
> > "select * from employee where id=?". Otherwise the problem do
> > exists.
>
>      Not true.  The state of each element in the set of root objects
> may be constructed from complex queries over multiple tables.  The
> objects reached from those root objects may be lazily loaded, again
> with complex queries.  Regardless of the complexity of those queries,
> there is typically no proliferation of finder methods.

I have seen a lot of finder proliferation in many different applications. You might claim that those applications are not wellwritten,  but they do exits. I could also add that your objects builts from complex queries is only one view of the data. The same data might be aggregated in many different ways. If those objects are mutable, anything could happen....

> >> Typically, once a core set of objects have been instantiated,
> >> access to related objects is via reference rather than repeated,
> >> explicit database access.
>
> > And obviously introducing synchronization issues...
>
>      You are assuming that the database is always the system of record
> and that the system is data-centric.  Those assumptions are not always
> valid so your "obvious" synchronization issues do not occur.  There
> are more ways of building large scale distributed systems than are
> dreamt of in your RDBMS.

Having mutable data structures in multi-user applications, will cause synchronization issues.

//frebe Received on Fri Feb 29 2008 - 17:38:46 CET

Original text of this message