Re: OOP - a question about database access

From: Paul Campbell (p.au.l.ca.mp.b.ell_at_ob.jectvi.sion.c.o.u.k)
Date: 11/20/03 

Date: Thu, 20 Nov 2003 12:59:03 -0000

"Costin Cozianu" <c_cozianu@hotmail.com> wrote in message news:bog9ng$1dhgg8$1@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.

Relevant Pages

  • Re: What application frameworks exist for Delphi?
    ... However if you do design one to one or one to many ... insist on handling the deletes itself when the database has a simple ... I have several employees in memory and run a batch update to increase all ... high-efficiency batch operations, and keep the in-memory object model ...
    (borland.public.delphi.non-technical)
  • Re: limit of lines?
    ... > Agreed, but don't let database design influence OO design, the two are not ... My framework has several rules ... > Customer ID ...
    (borland.public.delphi.non-technical)
  • Re: limit of lines?
    ... And this is the fundamental mistake in your design. ... a objects from a database, this usually leads to very poor design. ... Framework in which all properties are backed, not by a simple field, but by ... we have major size projects that use the Delphi template ...
    (borland.public.delphi.non-technical)
  • Re: PHP site development
    ... Every new architecture looks complicated at first. ... The next step is to create a new database table and see how long it ... The most important part of any application is the database design - if you ... This is true whether you have a framework ...
    (comp.lang.php)
  • Re: OOP - a question about database access
    ... >>When the structure of the database permeates through the business logic ... but it is known that UML has severe deficiencies ... design and OO design evolve almost in parallel (or course DB design can ... send method calls to modify the needed object data in memory ...
    (comp.object)