> >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/
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.
