On Fri, 6 Sep 2002, Craig Tataryn wrote:
> Date: Fri, 06 Sep 2002 12:41:26 -0500
> From: Craig Tataryn <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Alternative Datsource Hot-potatoing...
>
> I was wondering if someone could give me a heads up on some alternative
> means for which to give my data access layer access to my datasource.
>
> I don't really like the idea of my controller grabbing the Datasource,
> passing it off to my business layer, who in turn passes it along to my data
> layer. I guess I'm sort of a purest, but I don't think the Business layer
> should know anything about the database, and that means it shouldn't even
> have methods that take connections or datasourses as parameters.
>
> I think the only thing I like about the Controller passing along a
> connection to my business/data layer is the fact that I can first open a
> transaction before passing the connection along, and then I can commit the
> transaction when everything is done. Thus my transactions are at the
> controller level, and can be managed there.
>
> Back in my old VB/COM days, we had a sort of DB Utilities class which could
> be accessed from the datalayer. You would ask it to give you a connection,
> and it would get it for you. Should I make my own class for datasource
> access which is intitalized upon application start with the Datasource
> object found by struts? Then the rest of my datalayer can simply use it?
>
Three basic options exist:
* Hand a DataSource (I normally prefer to send a Connection instead, but
either works) to your business logic method as a parameter to each call
that needs it. Advantage: no binding to anything. Disadvantage: can
be a pain to hand it around.
* Static methods ... Most DB connection pool implementations offer a way
to retrieve a DataSource or Connection via a static method. Advantage:
no handing around extra method parameters. Disadvantage: ties you to
that connection pool's APIs.
* JNDI resources -- All J2EE app servers (and some servlet containers like
Tomcat 4) offer support for JNDI resources that are accessible to your
business logic directly like this:
import javax.naming.Context;
import javax.naming.InitialContext;
InitialContext ic = new InitialContext();
Context ctx = (Context) ic.lookup("java:comp/env");
DataSource ds = (DataSource) ctx.lookup("jdbc/EmployeeDb");
where "jdbc/EmployeeDb" is a resource reference you have declared in
your web.xml file. Advantage: No parameter passing, no connection
pool API lock-in. Advantage: configuration of the data source is
external to your webapp (it's done with the server configuration
capabilities). Disadvantage: container must support this.
For info on how to use the third option in Tomcat, see:
http://jakarata.apache.org/tomcat/tomcat-4.1-doc/jndi-resources-howto.html
(NOTE -- if you're going to use Tomcat, definitely go for 4.1; 4.0's
support has problems for many users).
> Thanks,
>
> Craig.
>
> Craig W. Tataryn
> Programmer/Analyst
> Compuware
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
