I just built a fairly large database application with Delphi. Keeping
"business logic and engine type code" separate from user interface code
was a goal which was severely broken. This due to the use of dataaware
controls. With dataaware controls the logic gets tightly bound to the
user interface. For my next project I therefor plan not to use dataaware
controls, but instead unbound controls. With this strategy I can easily
separate UI, database code and data validation code.

I would like to know how other developers do this separation.

Can you manage this with the use of dataaware controls, and if so how?

My next project is a database application using ODBC-interface towards
the database engine. I plan on using direct ODBC-calls instead of the
standard data components. Does anyone have any experience of this? Is the
overhead of this procedure significant?

Magnus G?fvert.

: I just built a fairly large database application with Delphi. Keeping
: "business logic and engine type code" separate from user interface code
: was a goal which was severely broken. This due to the use of dataaware
: controls. With dataaware controls the logic gets tightly bound to the
: user interface. For my next project I therefor plan not to use dataaware
: controls, but instead unbound controls. With this strategy I can easily
: separate UI, database code and data validation code.

: I would like to know how other developers do this separation.

        I tried the same thing and ended up ditching my separation
        and going with data-aware controls.  The reason was that creating
        master-detail forms by hand (with code) is a lot more work
        than simply draging and droping a few components...

: Can you manage this with the use of dataaware controls, and if so how?

        My compromise was to use data-aware controls and put my
        logic in separate units that would be called when ever
        the database (table) changed (posted).  This is not an
        ideal solution (doesn't help too much with queries).  The
        real trend is towards 3 tiered database developement and
        I too would like any insite as to achive this (without
        adding too much extra work) with Delphi...

        brant
        ...

In article <44b8dq$...@nic.lth.se>,
   f9...@efd.lth.se (Magnus Gaefvert) wrote:

Yes, this is a real issue; we get all these easy to use DB tools with
Delphi, but if we use them, we can't separate the UI from the business
rules.

Let me (and everyone else here) know if you find a way to do this.  I have
seen numerous references to what a good idea this is, but not one
implementation.

-Kyle

*****  Kyle Cordes @ Automation Service  *****  kcor...@mo.net  *****

One approach that I have been thinking about towards this
problem is a specific database component that encapsulates
rules for a table. If a componenent were derived from a TQuery
component that held all of the business rules needed for data
validation for a table then data aware components could be
used.

Yes, using this approach would create a mountain of
componenets. Is it really worth it, however, to reinvent an
object oriented ODBC API? If the goal is to seperate UI code
from API code then the work should be able to be done in
Delphi. It isn't worth the time to recreate API calls to ODBC
when component writing is the answer.

I know your other incentive for ODBC is redistribution issues.
What are these issues? I thought IDAPI could be redistributed
freely?

Tom Waterhouse
OMTI
t...@a.crl.com