Re: OOP - a question about database access

"Paul Campbell" <p.au.l.ca.mp.b.ell_at_ob.jectvi.sion.c.o.u.k> wrote in message news:1069333136.99655.0_at_putney.uk.clara.net...
>
> "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.

plonk Received on Thu Nov 20 2003 - 14:26:24 CET