struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Petrie <Dan.Pet...@harborfund.com>
Subject RE: [OT] What do you do with your SQL?
Date Fri, 26 Jul 2002 20:27:49 GMT
Hi Chris,

You may want to explore the idea of a DAO Factory.  We currently use such a
mechanism to retrieve a runtime interface to handle all database
interaction. The implementation of the interface (i.e. class name) is
specified in a properties file that is read at deploy time.  So...to handle
multiple clients you would simply need to implement this interface for the
client and specify the implemented class name in the properties files that
the DAOFactory reads from.  This allows you to keep the structure of the
application in tact with only needing to modify a properties file when
building the app for the individual client.  The business object classes
would then retrieve a DAO interface from the Factory.  This could work as
follows:

InterfaceName interface =
(InterfaceName)Class.forName(FullyQualifiedImplementedClassName).newInstance
();

We currently use this to handle multiple database servers (Sybase, Oracle,
etc) for our apps.

I hope this helps.

-Dan -

-----Original Message-----
From: Assenza, Chris [mailto:cassenza@Accessdc.com]
Sent: Friday, July 26, 2002 4:17 PM
To: 'Struts Users Mailing List'
Subject: [OT] What do you do with your SQL? 


Hi all, 

Been a while since I last wrote, but I've been lurking to observe all the
crazy antics. :)  Anyway, I've got a question of an [ot] nature that I
believe you folks will have an answer for. 

Our application is highly data-driven and as such a lot of our "business
logic" is written to build SQL statements and handle query results.  Pretty
typical stuff.  Using Struts we pass data objects to a stateless session EJB
where all the SQL is directly embedded into the java source one way or
another.  

We're currently converting this custom app into a product. As such, we need
to be able to have easily modifiable SQL statements without requiring
recompilation of code.  For example, if client A decides to buy our app and
they have xyz infrastructure or business rules, we need to be able to easily
modify sql, hints and the like while also supporting the client-specific
sql, hints, etc. of client B.  

A lot of our SQL is built on the fly so using properties files may be a
little cumbersome, though certainly not beyond our means.  I have other
ideas floating around, but I'd rather just hear yours - any suggestions? 

Thanks,

Chris


--
To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>


**********************************************************************
Note: By opening this email and/or any attachments 
contained within this file, you assume sole responsibility for 
any alteration of data that may occur as a consequence of 
any data transfer or copying process.

The information contained in this message may be 
privileged and confidential and protected from disclosure.
If the reader of this message is not the intended recipient,
or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.

For more information on Harbor Fund's privacy policy please
visit http://www.harborfund.com/privacy.htm

Thank you.

Harbor Capital Advisors, Inc. One SeaGate. Toledo, OH-43666. 
Tel: 419-247-1940  
Email: customer.service@harborfund.com
**********************************************************************


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message