Re: OOP - a question about database access

Costin Cozianu wrote:

> <snip>
>
> IN any case, the behavior model, even in "OO" terms is centered around
> use cases (transactions). When you resolve these use cases, they
> typically define the system going from point A to point B.
>
> It is an OO suboptimal approach to take the system from point A to
> point B by always and unconditionally applying the following mechanism:
>
> 1. load the object model (or the part thereof affected in the use
> case) in memory
> 2. send method calls to modify the needed object data in memory
> 3. send the commit call to a Context object (alternatively to the
> UnitOfWork object), at which point the framework executes :
> for each object in the object model
> if (object is modified)
> replay in memory updates as SQL updates
> database commit
>
> Which is essentially how all "design your objects as if you didn't
> have a database" solutions work. It's not for no good reason that we
> have so many bad O/R mapping frameworks out there, including the worst
> design of them all, EJB

Unfortunately, this approach is similar to many other multi-tier systems I've seen. Inside the business rules tier each transaction starts with /no/ data for validating, and trips are made to the RDB to validate and qualify the transaction before starting it. Tragic waste of DB resources and a real buzzkiller to performance.

>
>
> That's because folks have repeatedly tried to make the above algorithm
> work, and many times it works even if it is suboptimal, but for a lot
> of serious usage it *does not*, i.e. it is either straight impossible
> to make it work or the consequences in terms of performance penalty
> and locking behavior show quite severe, especially under stress load
> (typically in QA).
>
> Time and again, I found that for getting the system from point A to
> point B would require N queries/updates on the optimal path, while if
> they look in the logs it takes a whopping
> N * (OO bigotry factor)
> Where the (OO bigotry factor) can be in many case in the range of
> 10-100 rather than the 1.0 to 1.2 to be expected and accepted

Nevermind the OO Bigotry Factor, it seems more to be an "inexperience factor" since I've seen the same mistakes in C. I've even documented one at
<http://gagne.homedns.org/~tgagne/articles/newdef.html#casestudy1>. The solution also works well for OO designs. Static tables (collections) can be read as part of initialization and the transaction reduced to one DB read trip and one DB write trip.

-- 
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org