Re: What application frameworks exist for Delphi?

Hi,

<flameprotectivesuit on>

No need--OPFers are generally very nice people <g>

Im reliefed to hear that ;)

Actually I'd argue that this is a design decision that belongs in the BO
layer.

ok... I agree on that. However if you do design one to one or one to many
references and specify those on the persisted object, then I would expect it
to keep referential integrity.

And it's really not that interesting a behavior. If a cascade delete
relationship exists in the db between a main object and its dependents,
then all that needs to happen in the OPF is that when a master is deleted,
dependent objects are freed. There's no reason at all that a OPF should
insist on handling the deletes itself when the database has a simple
facility to do that.

But not all databases has that. Thats imo another pitfall about some OPF
designs... they are sometimes designed with specific datastorages in mind,
rather than being datastorage agnostic.

framework handled that quite nicely. However that also means that
accessing one object often brings in much more information than is needed

As Joao pointed out, lazy-loading is a well understood OPF approach.

Yes, but scope management is a less well understood topic or at least a less
well controlled topic :)

To me, this is a core issue: because what you're saying is that it's hard
to support non-OO design over an OPF. Batch processing is generally data
processing, not an OO issue at all.

Mixed cases (incorporating specific batched operations into an otherwise
OO design) can be difficult, and I'd argue that the reason for that it
comes down to this: whenever an object exists in memory, then a potential
exists for uncontrolled discrepancy between the state of the datarow and
the state of the object. Which state has priority?

Concrete example:
I have several employees in memory and run a batch update to increase all
sales employee commissions by 5%. Now the employees in memory have a
different value for their commission rates than the database does, but
since the change didn't go through the employee object, the objects
instances believe they're 'clean'--that they represent the current, true
state of things as retrieved from the database. So any subsequent action
concerning the employee instances (such as crediting them for a sale)
becomes suspect.

Now this problem does have a solution (besides the obvious one of not
allowing non-OO batch operations). When the object that executed the batch
update (a salary change agent, for want of a better term) learns that its
change has committed, it must broadcast a message about this, allowing
every employee that happens to be in memory to get the new information and
update itself without changing its clean/dirty status. Now we no longer
have uncontrolled changes--we've provided a mechanism that will both allow
high-efficiency batch operations, and keep the in-memory object model
instances current to the 'gossip' that has gone on with the database
behind their backs.

Except this dont work well on multiple application server scenarios. It
works fine on a client/server setup though.
State should in those cases always be stored in the db asap and be used
whenever the data is referenced.
In those cases scope management will start to have issues with data versions
etc.

Obviously not a trivial solution. For example, a complex where clause has
to be matched to a memory filter that will allow each memory instance to
decide whether or not it belongs in the affected set. Hence most OPFs
either ban batch operations (no bypassing the object layer), or end up
having to implement a fairly complex OCL that will allow/querying.updating
batches of in-memory objects. MS's Linq technology becomes very
interesting ...

There are lots of interesting ways to make life harder for one self ;)

All of this by way of saying

its real easy to get a mess out of things.

and it might be much easier over all to use an OPF application for day to
day data entry and maintenance, but confine high impact batch operations
to a separate, non-OO app that doesn't have to worry about synchronizing
what's true in the database and what's true in the in-memory object model
instance.

I agree on this. But imo it doesnt only relate to pure batch operations. Its
imo directly related to the business wise complexity of the application
which way is the best way.

actual datafield. Other methods using briefcase memory tables etc. like
kbmMemTable are usually more forgiving in changes.

I don't understand this claim. A briefcased object and a briefcased
datarow have exactly the same problem if the master schema is updated
while they're out. In fact, a briefcased object is likely to store itself
offline as a datarow on the local system, so I don't see why the in-memory
approach has anything to do with the problem being alleged.

The problem wouldnt be exactly the same as the memory table would be able to
read the data without necessarely knowing about any new format.
The fields that have same name would still be accessible. Its obviously an
issue with the fields that has changed, but it doesnt stop the client
application from at least reading old data in and decide what to do with it.

Is there anything here that doesn't apply as much or more to using a
heavily triggered database or business logic spread around under button
clicks?

I totally agree... which is why I also dont like heavy use of triggers (been
working on one of those beasts too - Oracle based application... also very
complex - for 5 years... no... it wasnt my design ;))


--
best regards
Kim Madsen
kbm@xxxxxxxxxxxxxxxxxxxxxxxxx
www.components4developers.com

www.myc4d.com - Your access to cool code
blogs.myc4d.com - Your access to code tidbits and comments

The best components for the best developers
Application server enabling technology for developers


.

Quantcast