On Fri, 6 Sep 2002, Craig Tataryn wrote:
> Date: Fri, 06 Sep 2002 15:16:13 -0500
> From: Craig Tataryn <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Alternative Datsource Hot-potatoing...
>
> Thanks Craig. I'll take a look into option 3.
>
> Could you see a problem with me creating a class called "DataAdaptor" with a
> static method called "getConnection()" which is initialized apon application
> startup with the DataSource setup by Struts? Then using this static method
> in my data objects to grab a connection?
>
Isn't that basically option 2?
The only disadvantage is that, unless you're careful, your DataAdaptor
class will be dependent on Struts unless you make it have a static
setDataSource() method or something. But you're still tying your business
logic classes to the presence of DataAdaptor in every program that uses
this approach (which may or may not be a big deal).
> Craig.
Craig
>
> >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >Subject: Re: Alternative Datsource Hot-potatoing...
> >Date: Fri, 6 Sep 2002 11:40:48 -0700 (PDT)
> >
> >
> >
> >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]>
>
>
> Craig W. Tataryn
> Programmer/Analyst
> Compuware
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
