Re: The Zen nature of a Delphi database application

Maarten Wiltink wrote:
"marek jedlinski" <marekjed@xxxxxxxxxxxxxxxxx> wrote in message
news:dqc7t2l4f409mui7fs9pa3s3kies3u1g6e@xxxxxxxxxx
[...]
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?

The state of the art is to do (b). It's more work up front, but it's
better and it _can_ be done.

It _can_ be done, but it should be done only if it's the "best" or "easiest"
solution, not only because "it's OO".

And it's a lot less work if (when) you
want to go back and add or change something.

No. It means you need to change your database AND your classes. IMHO,
classes are alternatives when their metadata can be used all through the
application. If data definitions come from the database, better use
string-based storage like xml or TStringList of TStringLists...

Subscribe to borland.public.delphi.oodesign and read back a year or so
(it's not a busy group). You will learn exactly everything you want to
know about business object, data packets, lazy loading, object
identifiers, and separating UI, business model, and backing store from
each other.

....and do yourself a favour not forgetting that OO nerds are the worst
fundamentalists of all in IT world.
*Then* listen to their good advice ;-)

--
Bjørge
'93 TDM850
bjorge@xxxxxxxxxxxx


.

Relevant Pages

  • Re: The Zen nature of a Delphi database application
    ... results directly to UI controls, then write data from the controls to ... then write data back from the modified objects to the DB for storage? ... I load the whole contents of the database into my business objects, ... I have dreamt of the perfect OO database application framework ...
    (comp.lang.pascal.delphi.misc)
  • Re: OODesign - OPF, design pattern
    ... the business object? ... I will let Peter tell you further about what he uses but, if you don't want to use ECO, of which I know Peter is a fan, then the easiest way to get UI controls to talk to business objects is to design adapter classes that know how to mediate between the controls and the properties of your objects. ... TDataset and TDataSource are simply adapter classes that are specialised to deal with connecting UI controls to database fields and tables. ... The biggest difference that I notice between the TDataset approach and something like MVP, is that TDataset is focused around always connecting controls to sets of data, whereas MVP can just as easily connect to single objects as well as lists of objects. ...
    (borland.public.delphi.non-technical)
  • Re: multiple subform images per main search form record
    ... Document ScreenDumps of: ... get a marker and label all controls with the Name property so when you ... save your word doc in the directory with the database you are documenting ... Show Images from Continuous Subform ...
    (microsoft.public.access.formscoding)
  • Re: When to (not) use the ADO data control
    ... > over is that you should use unbound controls in favor of bound controls. ... simple database program for your own use, ... > programmer that wrote the application used a mixture of DAO data controls ... I am by no means an advocate of bound controls. ...
    (microsoft.public.vb.general.discussion)
  • Re: Setting a referenced object to null
    ... "The controls" is an extremely non-specific description. ... of data that is fetched from a database. ... the variable reference something else. ... need to filter what is seen and what is not seen. ...
    (microsoft.public.dotnet.languages.csharp)