From: "Vahan Yoghoudjian" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, April 28, 2006 2:24 AM
Subject: RE: [delphi-en] Re: Why not use use db-aware controls.
> One more advantage concerning the usage of non data aware components:
> compatibility between database platforms
I agree with this one (see my previous post): in my last job there was a
3-tier setup (Interbase) in a project not yet complete, but 5 years old:
another client wanted to use Oracle: solution used was to make a second
project with Oracle objects and develop the two in parallel: any
modification made to one had to be made to the other (in a project taht was
already highly disorganised); the concept of unifying the code to work on
different databses (single executable or conditional compilation had not
occured to anyone) was not even taken into consideration;
In my opinion the client side should not have undergone any modification in
any case (ideally the problem could have been solved by changing the
connection parameters on the server, but there again, pigs might fly!) but
you know what happens when decisions are left to management with limited IT
skills: the Dreaded Crippling Quick Fix [DCQF] - "You know, we have
deadlines!";
[
Quick Fix [QF]: is sometimes innocuous since you can client delivery may be
on time, and the code can be sorted out later: the main problem is that it
is habit forming and that remedial correction frequently does not take place
Crippling Quick Fix [CQF]: an OOP technique used by management: it is the
accumulative effect of unremedied QF's, typically resulting from an
inherited primary QF object, to the point that there is damaged
functionality and remedial measures are beginning to prove inneffective;
Dreaded Crippling Quick Fix [DCQF]: similar to CQF, except there may be
multiple CQF's already; marked by ostensibly total disfunction; principal
diagnostic symptom is manifested when the project leader takes progressively
frequent leaves of absence, retreats into an uncommunicative shell or in
extreme cases disappears completely to re-emerge in employment with another
company;
]
It's not that data-aware controls cause the problem itself, it's that
methodologies dependant on them tend to provoke this sort of problem:
alternative (more efficient) solutions will often gain no advantage from
data-aware controls, or may even be simpler without them;
I favour the use of code to connect components (you can see what's going on
in debugging) and this includes assigning datasets at runtime; the fact that
the .dfm file 'hides' data is helpful at times and a hindrance at others;
Other (db-aware related) things that gets up my nose:
Master-Detail linked tables: I prefer passing the lookup field to an SQL
function to return the Detail dataset and displaying it as I want;
Calculated fields: calculation best done in a view or in sql on the server;
PersistentFields: I return the correct fields in the format desired and use
them as they are;
Big Datamodules: Aaargh!
Events in dataobjects: too easy to cause hidden confusion;
tTable: obsolete anyway if you do everything with SQL;
Kevin
-----------------------------------------------------
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.
