Re: Coupling or not coupling database and GUI libraries (was: GWindows and a future home for it)

[David Botton <david@botton.com>]

I'd like to point out that the Database code in GWindows is in fact 
_not_ tightly coupled, although it offers a system to graft database 
functionality on to controls if one would wish to do so.

Personally, I like doing things myself :-)  Which is one reason I allow 
for it to be decoupled easily.

David Botton


On 2004-10-21 14:02:17 -0400, Ludovic Brenta 
<ludovic.brenta@insalien.org> said:

> As a backgrounder on my experience: a few years ago, I wrote a 120
> kSLOC application in Java that did just that - an interface to a
> database.  The front-end started as Swing but changed to HTML and a
> bit of Javascript.  There was an abstraction layer over the database
> that supported Oracle, DB2 and DB2/400 and provided the database
> schema metadata to the visualisation layer.  There were a connection
> pool, several caches of metadata and data, and application-level
> permission settings (authentication was delegated to the database
> server, authorisation done in the application).
> 
> I have several concerns with tight integration of GUI and database
> libraries.
> 
> 1. If every widget can be attached to a database query, will every
>    update to a widget not cause an SQL query?  This should be avoided.
> 
> 2. If every widget is attached to a query, is it possible to update
>    several widgets with one query, i.e. that several widgets be
>    attached to the same query?
> 
> 3. Is it possible to perform arbitrarily complex, application-specific
>    formatting to the data as it goes back and forth between the
>    widgets and the database?
> 
> In the application I mentioned, we would routinely do queries that
> joined 5 or 6 tables, and we had lots of heuristics to help speed that
> up.  In one of the screens, we would present a tree structure
> constructed from oh, perhaps 10 different queries.
> 
> I have not really had a deep look at either Delphi, MFC, or GWindows,
> but I suspect that coupling the GUI and the database libraries is only
> useful for quick-and-dirty work when you want to create forms where
> one form=one record in the database.
> 
> But for anything more complex, such coupling just gets in the way.  In
> fact, it is the job of any non-trivial database GUI to perform the
> "grunt work" you mentioned, and I cannot think of a useful way the
> library could ease that.  Or perhaps you were only thinking of
> marshalling and unmarshalling of individual database fields to and
> from the database?  Yes, this is grunt work, but it is often
> application-dependent too.  And unlike Java, Ada has generics which
> can be instrumental in making this grunt work a piece of cake.
> 
> Java's JDBC is not tightly coupled with Swing or AWT.  Both APQ and
> GNADE are similar in concept to it, or the ODBC API which is also not
> coupled with any GUI.
> 
> I do not think it is wise to have a GUI-dependent database library.