A comment in itself that could convince me to abandon data-aware controls;
----- Original Message -----
From: "constantijnw" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, April 27, 2006 1:00 PM
Subject: [delphi-en] Why not use use db-aware controls.
> Hi,
>
> What are compelling reasons not to use db-aware controls?
>
> Constantijn
One reason that i can propose is where you wish to keep the invisible
database logic separated from the visually displayed data:
a good example might be where you have an RDBMS back end capable of working
on multiple databases (imagine Interbase/Oracle/MsSQL) which have to be
transparent from the GUI point of view, and you want a normal VCL front end
and also a Webbrowser based one:
If you separate the datalogic from the visualisation, you may find it a lot
easier using non data-aware components: you read in the variables you want
using object oriented functions and you insert them into simple VCL
components or dynamic web pages;
Validation of user data input can often be handled more simply: validate the
variables locally and pass them to object oriented functions in separate
modules which handle the database logic; validation is best done in the
invisible datalogic part, not in the module that displays the input data;
you can then develop one invisible datalogic module and make as many GUI
modules for it as you want, without having to write validation code for each
one: once you have a structure of this type, datalinking of visual controls
is not a great advantage;
The use of dynamic functions rather than statically linked data-aware
components can reduce the size and complexity of a program: the same
function used two hundred times instead of two hundred components dragged
onto the project at runtime; since the functions accept variables read from
the GUI, there is no need for them to be directly dataconnected;
A solid OOP database structure may be recompiled easily across different
versions of Delphi/Kylix or whatever other Pascal compiler you are using
since the objects that I describe are native, or else non visual: such code
is more easily cross-compiled; I have structures which can be put together
in one language, say Delphi, and which generate similar code in C#, Java, C
etc along with the SQL functions required for the database side (complete
with syntax variations for the different SQL dialects: Oracle/Interbase
etc): data-aware components are COMPLETELY USELESS in this context;
I find the database OOP approach that I have described much more elegant and
modular and conducive to good design; it favours re-use of code which should
reduce bugs and keep everything more compact;
Data-aware components, in making things deceptively simply, can inculcate
untidy thinking and laziness, which can lead to very untidy design;
confused use of before post, on post, after post, onupdate etc
(clientdataset has about forty events to play with, and with fifty say of
them on a module, imagine the mess you can cause);
I am mainly concerned with SQL Inserts, Updates and Deletes, updating the
display, calling stored procedures and managing their parameters;
Data-aware controls could be used, but a function for loading data into a
non data connected object will often be fine;
-----------------------------------------------------
Home page: http://groups.yahoo.com/group/delphi-en/
To unsubscribe: [EMAIL PROTECTED]
SPONSORED LINKS
| C programming language | Computer programming languages | Java programming language |
| The c programming language | C programming language | Concept of programming language |
YAHOO! GROUPS LINKS
- Visit your group "delphi-en" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
