13

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

Fabio Vitale
  • 2,257
  • 5
  • 28
  • 38
  • 8
    +1 because I like the question, but I'm in the never-use-Db-aware-controls camp, so I'm not going to answer. – Cosmin Prund Jan 19 '12 at 09:31
  • 1
    It depends which control, dbedit etc are fine but sometimes things like dbgrid leave a lot to be desired – Simon Jan 19 '12 at 09:48
  • 4
    +1 For small DB application (which I need fast solution) I would go with DB Aware Controls, especially if the DB is local (Like MS-Access). For a Large scale and completed DB applications I prefer to use my own non-aware controls. for Example for DBGrid I use Virtual Tree where the DataSet is not binded. It's a lot more work but at-least I'm not restricted. – kobik Jan 19 '12 at 09:58
  • @kobik: small apps tend to grow into big apps and having started with DBAware controls it takes a lot of effort to go the other way when you should. – Marjan Venema Jan 19 '12 at 10:00
  • @Marjan, you have a point. problem with Db Aware controls, is that they are already there just waiting to be placed on the form and quickly linked to a DataSource... it's tempting to just go ahead and finish with it :) – kobik Jan 19 '12 at 10:05
  • 3
    I am with @Cosmin, though I sometimes think the DBAware controls in and of themselves aren't the problem, but the way you use them. They tend to lead to all business logic coded in events of the form. If you avoid that, group your datasets on datamodules and put your business logic in events of the queries you are already better off. Put your business logic in classes instantiated when the datamodule is instantiated and business class methods called from the dataset/module events and you set yourself up for a far easier switch to properly separated layers when your app grows up. – Marjan Venema Jan 19 '12 at 10:06
  • Possible duplicate of http://stackoverflow.com/questions/4722563/using-delphi-data-aware-components-pros-and-cons – mjn Jan 19 '12 at 10:42
  • Investigate LiveBindings in XE2; Benefits: Cross platform (Win32 VCL + Firemonkey on Win, or Mac) – Warren P Jan 19 '12 at 20:02
  • The primary advantage is speed of development. I recommend using TClientDataSet or some other memory table if you're using data-aware controls. More info from one of my past answers here http://stackoverflow.com/a/4731116/60004 – LachlanG Jan 19 '12 at 21:33
  • 1
    When I first read the title of your question, I had the same opinion as @CosminPrund ... because personally, I like objective comparisons. But then, on reading the text of your question, I realised all you really want is some ammunition to "prove your friend wrong". Your mind is made up, and you're not interested in an objective comparison. This really isn't conducive to learning. You might as well ask for arguments why your religion is right and his is wrong. – Disillusioned Feb 09 '14 at 16:13

5 Answers5

12

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.

Fabricio Araujo
  • 3,810
  • 3
  • 28
  • 43
10

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.
da-soft
  • 7,670
  • 28
  • 36
  • 1
    I'm a fan of data-aware controls but I disagree with your second pro. Even if the controls implement MVC (and I don't believe they do) that doesn't mean your code does. You have to make an effort to correctly layer a data-aware controls application, it's not an automatic result of using data-aware controls. – LachlanG Jan 19 '12 at 21:42
  • @LachlanG: Delphi is a kind of MVC-like if you use TDataModule correctly: Form-> controls + TDataSource; Form *.pas -> command the interface and asks for data; Data Module: methods for data retrieving and updating answering the requests of form. – Fabricio Araujo Jan 24 '12 at 16:37
  • @FabricioAraujo: I strongly disagree. No matter how you use them they're nothing like MVC. I'm not saying that MVC is necessarily better or worse than data-aware components just that the two are very different approaches with very little in common. – LachlanG Jan 24 '12 at 22:42
  • @LachlanG: we'll have to agree on disagree. You doesn't necessarily an entire separate class to do the controller role. – Fabricio Araujo Jan 25 '12 at 17:28
8

Both DB-aware and non-DB-aware components have advantages and disadvantages, depending on what kind of application you are developing.

For small-to-middle scale applications, using DB-aware components is encouraged, unless there are specific requirements or conditions under which those applications are operating. For example, a simple data entry application would be easier to develop and maintain with DB-aware components. Even middle-to-large scale applications, if properly designed and implemented, will have good performance with DB-aware components.

However, when developing modular applications, especially multi-tier systems, DB-aware components can have negative impact on application performance and maintainability. This is particularly noticeable with applications that access data over the Internet. Main reason for this is because DB-aware components require a constant connection to the database, which can significantly increase network traffic.

Using non-DB-aware components can be more complex since it requires better understanding of the underlying mechanisms, but in multi-user and distributed multi-tier environments it scales far better than anything else. Additionally, you can (and should) separate the data-access layer from the presentation (UI) layer, which will later allow you to make changes to one subsystem (module, layer) without having to to change anything else.

Today, data can be anywhere and most of the times it is not stored on local computers or networks. Using DB-aware components to access that data can have significant negative impact on application and database performance. There are some data-access layers which improve this (UniDAC, AnyDac, ...), so using DB-aware components with them may get you better performance. Still, non-DB-aware components can outperform anything.

It is up to the developer to decide which mechanism to use, because, as I said, it all depends on what kind of application you are making and in what environment will it work.

LightBulb
  • 964
  • 1
  • 11
  • 27
  • 1
    +1 because the only answer to explicitly name "[multi-tier](http://blog.synopse.info/post/2010/08/19/How-to-implement-multi-tier-architecture-in-our-SQLite3-Framework)" layered architecture. In short: DB-components are hell to maintain and scale. And worth speaking about the [Service Oriented Architecture (SOA)](http://blog.synopse.info/post/2010/07/18/DataSnap-like-Client-Server-JSON-RESTful-Services-in-Delphi-7-2010) approach. RAD DB components are typical 1990's dev: it's nice for prototyping and small apps, but for business applications, it is to be avoided in 21th century. – Arnaud Bouchez Jan 19 '12 at 12:08
  • `DB-aware components require a constant connection to the database`. Only true if you link directly the data access components to the controls. Otherwise, the DB-control will ask TDatasource for data and it will come from whatever it is... – Fabricio Araujo Jan 23 '12 at 18:15
1

This may be a carryover from experience with Visual Basic. As I recall, even Microsoft told developers not to use DB-aware controls in production code.

Delphi never had that problem, but as others have said, it depends upon the kind of project you are building and whether you run into performance issues.

Graham
  • 667
  • 3
  • 9
0

Anecdote: a DB-aware control once messed up our InterBase database: to indicate a 'empty' or null date, the date edit control TcxDBDateEdit (ExpressQuantumGrid) uses a negative date value, which represents literally "01/00/0000".

So when users cleared the date edit field in the input form, and posted this value to the database, the records became unreadable (SELECT statements failed).

mjn
  • 36,362
  • 28
  • 176
  • 378
  • Anecdote: I once made a copy and paste error and saved the wrong value to the wrong field. Actually I've done that more than once. ;-) – LachlanG Jan 24 '12 at 22:48
  • 1
    An DateTime picker is a type of control that shows how careful (or careless) the programmer that created it is. I've saw a lot of DBAware DTPs that also incapable of handling an **null** situation correctly. – Fabricio Araujo Jan 25 '12 at 17:47