Re: OOP - a question about database access

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Fri, 07 Nov 2003 06:19:33 -0800
Message-ID: <bog9ng$1dhgg8$1_at_ID-152540.news.uni-berlin.de>

Paul Campbell wrote:
> "Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:boea7t$1df9lt$1_at_ID-152540.news.uni-berlin.de...
>
>

>>Your bias (and in general this bias permeates the entire agile gang )
>>comes from the fact that you don't really know how to work with
>>databases properly. You know objects much better (well, at least Java,
>>C++, Smalltalk and Python kind of objects ). Than this approach is
>>likely to work better for you.
>>
>>When the structure of the database permeates through the business logic
>>*and* the structure of the database is bad, you have a hard time meeting
>>changing requirements or providing good quality software.
>>
>>But that doesn't mean your approach is overall the best, or things
>>cannot be made differently.

>
>
> Indeed not, but the original poster didnt ask for the "best" solution, he
> asked for the OO one.

Now you come across as very funny as you think that there is

  *the*

     *OO*
        *one*

You may well be right that an OO solution
> to his problem is not the optimal one but that isnt he subject under
> discussion.
>

His advice is not generally advisable even for OO teams. I should know cause I helped a few guys get out of trouble. Sadly I have heard of numerous other stories of such instances, some of them were even as foolish as to advertise the problems they were facing and blame it on the database.

> Given that the original poster wanted an *OO* solution the general
> advise to drive the core behavioral model from the requirements
> and not an existing database is IMO the correct approach.
>

The core "bahavioral" model is a nice one.

But requirements have two major types of business rules:

• structural
• behavioral

Behavioral means little nothing without the structural. The structural business rules alone allows a team to define the "conceptual model" or "information model", reflecting the essential data that the whole software system (app + database ) should operate with.

In lay man's term it is an E/R or an ORM diagram (there are a few others like IDEF1X). If you're that much an OO bigot, you can even use UML for the conceptual model, but it is known that UML has severe deficiencies in this area.

Now once you've got that right (by the way, Uncle Bob wouldn;t go that far anyways , not even with UML because he's doing XP) the database design and OO design evolve almost in parallel (or course DB design can be done much quicker).

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

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

So the very prudent advise to give to a newbie is that he *should not* assume that he can design obejcts in memory as if there was no DBMS involved on the other side, because he might have the very unpleasant surprise to see that it does not work, or it works badly enough to get him in trouble.

The prudent advise is to take things with a grain of salt, and resolve the issues on use case by use case basis.

> Paul C.
>

>

Costin Received on Fri Nov 07 2003 - 15:19:33 CET