Re: The Zen nature of a Delphi database application

marek jedlinski wrote:

If I have a seemingly basic question about using a database in a
Delphi app, but can't find the answer in Borland manuals, or in
samples, or in Mastering Delphi 5/6, or in Developers Guide ditto, or
really anywhere else, then either it's something everybody else was
born with, or it's one of those Zen questions that defy reason. I've
no idea which it is.

I can understand your feelings ;-)

Should I (a) use database functionality ONLY, and connect query
results directly to UI controls, then write data from the controls to
the DB? Or, should I (b) read from the DB into objects that represent
the data (a "data model"), populate UI controls from those objects,
then write data back from the modified objects to the DB for storage?

I really want to do (b), but I'm getting nothing but puzzles when I
try. How can I build a list of my business objects, if I just said
their data is to be too big to fit in RAM (due to "blob" content)? If
I load the whole contents of the database into my business objects,
then I'm missing the whole point of using a database, aren't I?

If you do want to use them objects, consider using a proxy technique: If you
load a list of objects for some sort of display, don't retrieve all data
fields. Only those needed for display or locating purposes. Whenever you
need the guts of the object, reread the data, but now all field values.

I've started questioning the use of "business objects". For one - the fact
that they don't come with a lot of functionality helping you to create the
most complex part of the application: the user interface. Secondly, that
they add another set of problems related to representing a "limbo" between
physical storage and user interface. OK, there are frameworks out
there...but using one of these means buying the whole package. I have made
some 3 attempts to create such a framework, and I probably won't ever use
one of them or build another one. Data objects are in fact more useful in
languages like JavaScript & when "scripting" COM objects without using early
binding: Data objects' fields may be accessed without a lot of declaration
code.

To be honest, I have dreamt of the perfect OO database application framework
since I learned about OO. But I feel that you somehow address one major
obstacle; no single scheme will work well in a wide range of application
sizes and kinds. I spent a few years trying to come up with a general
storage interface that would be possible to implement in storages based on
flat files, databases and application servers. I ended up using a sream-like
interface, but I never solved one of the major issues in my model: How to
implement a collection whose total count in unknown, like db datasets are
(you access them by "next;", "prior";, etc., as opposed to "for i:=0 to
count-1") ? In my 2nd framework model, I created datasets that wrapped
collections of real objects. Not trivial. It solved some problems, but
deprived me of a lot of OO goodies.

I find myself writing less OO every day. OK, I use OO more for metadata than
for production data containers. If you don't need polymorphism, don't use
OO. A bit rough, maybe, but generally sensible. You need OO when you create
structures that extend your imagination at designtime. Like e.g. an HTML
renderer - I can't think of how to solve that problem non-OO. But a
customer - order - invoice - product - etc... type application gains little
from OO. When streaming - ok, as you need the object's class for data
definition purposes. But for db-applications the classes add yet another
location of metadata that calls for maintenance and care.

Or: each BO has a read-only UID property, passed as an argument to the
constructor. I cannot construct the object without the UID, but I
don't have the UID until I have stored the object in the DB, since
the UID is the autoincrement field. This one really puts a damp on my
thinking.

Most databases come with an ID generator, or you could create one. Before
creating any db record, get this ID. Stay away from "autoinc" fields - the
use of them cause your trouble.

Or, if my BOs are shown in a grid, and the user edits a value in a
single object, should I update just the BO, or both the BO and the DB
at the same time? If just the BO, when's a good time to update the
DB? And how can I ensure that the two don't go out of sync if a write
operation fails?

Well, the only good reason I can think of to store data in a local object is
when you really don't have the time to access the db every time you need
other data or when you modify it. Else you should update them as an atomic
operation.

I feel that all these questions are aspects of one and the same
fundamental issue. I've never had any of these problems when working
with stream-based storage, of course. What is eluding me?

A stream-based application may be a good, easy solution, but as you have
discovered - all-loaded-in-memory applications suffer from limitations on
data size. Also, they are not multiuser-friendly ;-).

One serious problem with applications built with db-aware controls is the
total lack of control over when data is retrieved or posted. The
object-based applications (or any "offline" type model) gives you the
opposite problem: A minor flaw may make it get out of sync and even not post
your user's modifications. That's the programmer's nightmare...
--
Bjørge
bjorge@xxxxxxxxxxxx


.

Relevant Pages

  • Re: Library vs Framework
    ... > had to do the same things: connect, grab data, create controls to ... > data back into the database. ... > code time and time again. ... > created your own framework as you've gone along. ...
    (comp.lang.python)
  • Re: Library vs Framework (was Dr. Dobbs Python-URL!)
    ... > Where a framework shines is when you don't really want to program ... Where a framework really shines is ... I've written several apps that need to update a database, ... had to do the same things: connect, grab data, create controls to ...
    (comp.lang.python)
  • Re: reiser4 plugins
    ... And have you ever heared of the problem of Wikipedia storage? ... reduced the database by 85%). ... Reiser4 won't provide anything but the storage part. ... What userland tools you use to acess this filesystem is upon your decission ...
    (Linux-Kernel)
  • Re: reiser4 plugins
    ... > an entire new storage array and this wasn't/isn't cheap. ... > following versions of an article; reduced the database by 85%). ... So a filesystem with intelligent ... Any "unnecessary double work" would squarely be within ReiserFS... ...
    (Linux-Kernel)
  • RE: Data storage solution advice sought...
    ... Data storage solution advice sought... ... > database, as it will allow. ... > my development), XML files, Pocket Access, SQL Server 2005 Mobile. ...
    (microsoft.public.dotnet.framework.compactframework)