Re: OOP - a question about database access

"Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:bog9ng$1dhgg8$1_at_ID-152540.news.uni-berlin.de...
> 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.

Again - the original poster is not working on a product, he is working on a *learning* excercise. Learning excercises have to be graded and feed in real world factors and complex issues (such as when to to do stuff in the DB and not in the OO model) one by one.

Treating an OO system as persised "by magic" is a valid learning excercise IMO even if such an approach is not used all by itself in a real world system.

> 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.
>

Right sentiment, wrong thread.

However given that we are here anyway Ill throw in a few comments ...

>
> > 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.

Well technically if you need "structure" as well as behaviour then your behavioural analysis is incomplete, but that is not necessarily bad. Whats happening here is that the behavioural analysis stops at the point where use cases start to look like stuff that is much more concisely addressed by ad-hoc queries on the behavioral model structure rather than specific behaviour for each case. Ive worked on systems that exhibited just such characteristics.
All I'm doing is pointing out that there is an alternative - to follow through with the analysis and ensure that the behaviour is indeed fully sufficient without the need for structural queries. On system with pure OODBMS facility without query you have no choice but to do this including the use of a pattern that I call "query amortisation" - accumulate data as we go rather than build it on demand, which obviously only works for quieries whose dimensions can be predicted ahead of time.

>
> 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

Well alot depends on access patterns - if were doing read-mostly access then the ability to reuse the data from already in memory objects could in theory offset the losses incured by a framework based memory-to-DB transactional update. Of course Entity Bean containers may not be yet at the point of sophistication where they allow any real gains here (and they arnt helped by a deficient spec). For pure transactional throughput then obviously an automatic framework cant compete with hand tuned SQL.

Paul C. Received on Thu Nov 20 2003 - 13:59:03 CET