Re: Coupling or not coupling database and GUI libraries

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Ludovic Brenta wrote:

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

Ah, but you had to _build_ something, which is fine. I am not
suggesting an _implementation_, but I do think it needs to
be handled somehow. To do this elegantly, I believe that
GUI and database packages need to at least plan for the
possibilities.

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

No of course not. This is configured at the point of building
the application (whether by GUI in Delphi or by some other means).

> 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?

Again, widgets are not hardwired to any database "concept". But yes,
it is possible in MFC for example, to associate multiple widgets
with column data. Someone with a better memory help me out here: there
is some kind of xfer event or API call.

> 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?

Complex cases always tend to be a "do it yourself" approach (no
surprise there). The there are many mundane cases that can be
handled elegantly. The simplest case is perhaps like the Dbase
case of a form matching a row of data (not using Dbase terminology).

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

Joins by themselves are not a problem if you're only presenting data.
Doing updates are a bit different of course.

What you want to do is eliminate most of the grunt work. You won't
eliminate it all, but you can do a lot of it. Out of a large
application where you might have 200 screens, most of them will
be stupid and simple, and I see no point in handcrafting it all ;-)

> I have not really had a deep look at either Delphi, MFC, 

Delphi and MFC had ways to make your life much easier with
databases. MFC fell down when it came to handling NULL values
in calendar widgets etc., but it tried.


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

I have to disagree.

> But for anything more complex, such coupling just gets in the way.  

Much of the necessary coupling is grunt work. We have more creative
things to be doing.

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

Well, you admit to not having tried it. Try it first, and then you
might see that there is at least a partial solution.

 > Or perhaps you were only thinking of
> marshalling and unmarshalling of individual database fields to and
> from the database?  

Nope. Column X must have its data populated in a control. WHen a
save occurs, you must do the reverse. Grunt work, plan in simple.
Multiply that by the number of column-widget pairs. More grunt.
It is also easy to automate this kind of stuff, with the right
kind of organization.

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

APQ is not currently linked to any GUI. I would like to perhaps
make a change on that score someday, but I haven't had much time
to plan it yet.

> I do not think it is wise to have a GUI-dependent database library.

Think in the larger sense of solving the problem, rather than its
implementation. How it is solved is unimportant to me, but it does
need to be solved. GUI and databases are frequently cousins.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg