What are the advantages of using DB Aware Controls instead of non DB Aware Controls in Delphi

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.

Answer 2

DB-aware controls pros:

1. The work to load data to a control and save data to a dataset is performed by VCL. You have less to code - really RAD.
2. The DB-aware controls + TDataSource + TDataSet implements MVC pattern. That helps to separate GUI and data access code.
3. The code validating, reformating, doing other post processing of the data will be called in well defined moments using event handlers. That helps to centralize such code and avoid confusions with the places where it should be placed. And avoid confusions with the moments when to call it.

Cons:

1. This is not a universal approach. You cannot bind a DB-aware control to a non-TDataSet data source. This issue was solved with introducing Live Data Binding in Delphi XE2.
2. Event driven programming may be confusing for some developers. And requires knowledge of TDataSource, TDataSet, TField events and architecture, and lead to controversy with Pros (3). Bad event driven code may be nightmare.