data-aware is a delphi standard about writting components which have a
datasource property, and a behaviour consitent with it. datasource
basicaly gives access to a DataSet (or descentent) that is an open
cursor. data-aware components have two-way access to the cursor: 1.
comunicates to the component that the cursor changes, so they would
know to update their status (and the screen,) 2. allows changing the
status of the cursor. 1 is when the cursor changes and the user has to
know. 2 is when the user wants to change the cursor or the data in it.
For example: 1. my db-aware component THFormula
(http://www.pathcom.com/~horiatu/delphi.htm) will re-evaluate
(interpret) the formula over the new values from the database when the
record changes; 2. a. a DBgrid will command the change of the current
cursor/record when the user wants it. 2. b. a DBEdit will allows
(somehow) the modification of a field when the user wants it.
So, as long as you implement the specifications of the db-aware, your
component can take advantage of working with open cursors. For
something else (disconnected databases for example) you should follow
other standards...
Note that 1. for "something else" there are also other component sets
which will simplify your development. 2. when using with (simple or
cascaded) cursors you may use or write data-aware components without
warring about the underlying databases as long as you can descend from
a DataSet your new component which gives acces to the database. 3. BDE
is just a way to use the db-aware standard and applies to most desktop
pr client-server databases. It is not the most efficient, but it works.
Other standards (as ADO) exists for other needs, and you may find other
technologies (as .Net) which will provide same benefits.
Another way to view this subject is in relation with the MVC model:
data-aware components will make sense in between the V and C parts:
they allow the GUI (V) to bind to the bussines-logic (C.) To port the
data to the phisical layer (M) from the controller (C) you should thing
to other transportation components.
Last (but not...) you may always use a stored procedure in a DataSet
(which is neccessary to use a db-aware component) as long as the stored
procedure returns a cursor. Even when the stored procedure does not
return a cursor, it may be used with other components (not exactly
data-aware) from the BDE or with most of other packages.
Another good topic would be to disect why to use stored procedures, and
there are mostly good things to say about, but is out of this topic...
Horia
----- Message from [EMAIL PROTECTED] ---------
Date: Fri, 28 Apr 2006 14:48:52 -0000
From: Glenn Lawler <[EMAIL PROTECTED]>
Reply-To: [email protected]
Subject: [delphi-en] Re: Why not use use db-aware controls.
To: [email protected]
>> You mean that db-aware controls are more complex and therefore more
>> difficult to maintain?
>>
>
> Not at all. They are much easier to maintain as long as you do not
> change anything about your application or the backend you are using
> that conflicts with the code that implements the control. The problem
>
> is, those kinds of conflicts happen a lot. My point is that when they
>
> do, you can spend more time coding workarounds than you would spend
> coding your own interface to the standard controls in the first
> place.
>
>> I'm working on an application server framework, also including
> basic
>> business objects. If I provide easy linking with db-aware controls
> I
>> need to hold their data in a TDataSet descendant. An alternative
> way is
>> followed by tiOPF which contains so called "persistent object-aware
>
>> controls". Also I could leave it to the user to create the
> link
>> between controls and the object's data.
>> Comments?
>>
>
> My comment is that the guys that created these components made them
> simple to use by hiding information. You can get the same effect as
> the data aware components using standard components. We have written
> our own library that binds all the standard windows controls to
> queries. We have completely eliminated the BDE and have written
> another library that goes directly to ODBC to communicate with the
> database. The way we have implemented both libraries that is
> different than the shrink wrap ones we have used is that they are
> highly granular. That is, there are both very high level and very low
>
> level calls you can make to our libraries that allow for complete
> control. For example, we have a BindControl call (a separate one for
> each standard control) in which you pass the control as a parameter
> along with a pointer to a library structure. After that single call,
> everything is handled by the library both to and from the control.
> However, you can do other calls that override just about anything you
>
> need to override in terms of the behavior of the control. Since we
> wrote the library, we can add any other functionality we need when
> that need arises.
>
> In general, my advice is this: Learn how to write software using the
> basic underlying language, in this case, Pascal. The main reason we
> started using Turbo Pascal many years ago and moved away from IBM
> Compiled Basic (written by Microsoft) is that the Pascal language was
>
> based on an ANSI standard, and Basic was not. If you do that and
> learn how to abstract and modularize (library) your code, you will
> find that you can make your own code just as easy to use as the
> shrink wrap solutions, but still maintain complete control over how
> it works.
>
> We try to use the Windows API in our libraries for greater control.
> APIwithDelphi is a group that is all about how to use Delphi in this
> way:
>
> http://groups.yahoo.com/group/APIwithDelphi/[1]
>
> We are in the process of porting a lot of our code to Linux and when
> you write you own libraries, you can achieve platform independence.
> We are currently investigating FreePascal for this with some success
> already.
>
> Glenn Lawler
>
> --- In [email protected], constantijnw <[EMAIL PROTECTED]> wrote:
>>
>> Glenn Lawler wrote:
>> > >What are compelling reasons not to use db-aware controls?
>> >
>> > When you are writing Client-Server systems, using standard
> controls
>> > instead of db-aware controls gives you a great deal of
> flexibility.
>> And more effort.
>> > For example, all the db-aware controls I have used will lose
> their
>> > data
>> > as soon as you disconnect from the database. When using standard
>> > controls. You can connect to the database, run a query to return
> data,
>> > populate your controls, and disconnect. This frees up a database
>> > connection. Most commercial Client-Server databases have a non-
> trivial
>> > cost for each simultaneous database connection.
>> >
>> Right, but in my case it's a multi-tier setup.
>> > There are many other reasons, this is just one. If you want your
>> > applications to work exactly the way you want, using someone
>> > else's component could cause you as much work as writing you own
>> > code when trying to get around undesired component behavior.
>> >
>> You mean that db-aware controls are more complex and therefore more
>
>> difficult to maintain?
>>
>> I'm working on an application server framework, also including
> basic
>> business objects. If I provide easy linking with db-aware controls
> I
>> need to hold their data in a TDataSet descendant. An alternative
> way is
>> followed by tiOPF which contains so called "persistent object-aware
>
>> controls". Also I could leave it to the user to create the
> link
>> between controls and the object's data.
>> Comments?
>>
>
> -----------------------------------------------------
> Home page: http://groups.yahoo.com/group/delphi-en/[2]
> To unsubscribe: [EMAIL PROTECTED]
>
> -------------------------
> YAHOO! GROUPS LINKS
>
> * Visit your group "delphi-en[3]" 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[5].
>
> -------------------------
>
>
> Links:
> ------
> [1] http://groups.yahoo.com/group/APIwithDelphi/
> [2] http://groups.yahoo.com/group/delphi-en/
> [3] http://groups.yahoo.com/group/delphi-en
> [4] mailto:[EMAIL PROTECTED]
> [5] http://docs.yahoo.com/info/terms/
>
----- End message from [EMAIL PROTECTED] -----
-----------------------------------------------------
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.
