> In fact, the Swing and JDBC components are completely and
> totally separate -- one of the options is to run the Swing UI component as
a
> browser applet, which makes RMI calls to the server where the JDBC
component
> handles the RMI calls. This would probably be the only kind of a "best
> practice", if there is one at all -- to keep the two components completely
> separated from each other, and use an intermediate API to communicate back
> and forth.
In general, I agree. It's typically not great to have a client component
access the database directly. First, it means that the client must have the
database userid and password, and the database must be accessible to the
client (which is probably okay over a trusted LAN, but definitely more of an
issue over the Internet). By using a server-side component (ala servlets or
EJB or even an RMI server), the requests from the client are handled by the
server, and the server can then use a database connection pool for all of
the client requests. Therefore, if you have 20 clients, instead of needing
20 connections to the database, you may only have a few since the server can
use a pool since it's unlikely that all 20 client connections would be
active all the time.
David