I wouldn't even store the DataSource. You may wish to have multiple DataSource instances you wish to use in a given project.
I have Business Objects that extends a "BaseBO" object, which are generated by a factory (the factory reads an XML file using digester). My DAOs are generated similarly. My BO knows the "name" of the DAO it needs to work and just calls it out by name, from the factory. I treat my BOs and DAOs as "effective singletons". By that I mean there is never more than one instance created through the factory (the class does not follow the singleton pattern though, since that works against inheritance). The DAO itself is configured to "know" the name of it's datasource and passes this down into the bowels of my SQL-execution subsystem that retrieves the apropriate datasource instance and executes a given query. How long does it really take to lookup a resource in JNDI? Not very ... and it's conceivable it could change on the fly (the system admin changes it through some admin tool, say). On Fri, 28 Jan 2005 09:23:38 -0700, Larry Meadors <[EMAIL PROTECTED]> wrote: > I would never reccommend storing a private connection object in a DAO > - that is why we have DataSource objects. Get a connection, use it, > close it, and keep the open time to a minimum. Using a DataSource, you > can open and close connections for almost no cost (in terms of time). > In addition, unit testing that kind of architecture is a major PITA > because of the setup required. > > Larry -- Eddie Bush --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
