Question

I would persuade a friend me that using Using Database Components (DB Aware Controls) in Delphi is by far the best option, when developing database applications.

This debated started with him many years ago: still today he is persuaded that using simple controls like TEdit, TStringGrid etc., with a set of getter and setter methods to populate them, is the best solution both in terms of flexibility and maintainability of the whole project.

To me this sound counter-intuitive at least.

I think that using DB Aware Controls, like TDBEdit, TDBGrid etc. is the right thing to do when developing database applications.

So: please help me convince him with sound advises about using DB Aware Controls!

Thank you in advance to all of you that will post at least his own advice, whatever will be in favor of one or the other solution.

—
fabio vitale

Answer 1

DB-Aware vs non DB-Aware is kind of a obsolete discussion. DB-Aware controls have automatic databinding, which means they autofills themself with data, do change detection and write to the members of the datasource bounded; in non-dbaware controls, it’s up to you to do those tasks. This can lead to messy code too – or overengineered frameworks just to do databinding. Both scenarios are bad.

The kind of datasource and the quality of the individual control will determine the performance. I’ve seen a lot of code to databind TStringGrid simply just to avoid TDBGrid because of purism (when TDbGrid would do nicely) – just a overly absurd loss of time.

It became an obsolete discussion when TClientDataset became the de-facto dataset for disconnected applications: you can pull data, disconnect, work on data, connect again and apply changes. Since CDS+DbAware controls will do 99% of the interface, you use the non-data-aware controls for the next 1% (for some complex interfaces).

I still don’t have XE2 to see if LiveBindings do the OO databinding work nicely – if so, now all controls can db-aware if needed.

EDIT: in da-soft’s answer, he(she?) argues that DbAware controls implements MVC pattern and LachlanG disagrees that, even it does, doesn’t that code itself is MVC. I’ll give my $0,02 cents here 😉

I think that the use of a 1:1 relation in DataModule and Entity (as in ERD) – or DataModule and a Form – you can get an application where responsibilities are separated:

• form dfm -> Layout and design-time databinding (have only Datasources)
• form *.pas -> controls interface and asks Data Module for data (acts like a controller)
• Data Module -> methods to answer forms requests for data retrieval
  and data updates

I normally have an separated data module for database connection which is passed through forms/entities’ properties.