Starting to look a lot like JNDI...(pronounced "Gin-dy", sung to a
familiar tune)
Seriously, look again at Craig M's option 3 -- if your container
supports it, the lookup and implementation abstraction can be handled
for you.
Craig Tataryn wrote:
> <see below>
>
>> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>> 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.
>>
> Number 2 was:
> * 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.
>
> I read this as I should use the static methods provided by the specific
> connection pool. What I meant was, I would create a generic
> DataAdaptorFactory class and a DataAdaptor interface which could be be
> configured off of a properties file to determine which data adaptor to
> use. This way I can abstract myself from implementation details.
>
> I don't think my business layer would even know about the DataAdaptor,
> they would be communicating with my Data layer objects, which would take
> care of data issues.
>
> Something like:
>
> public interface DataAdaptor {
>
> public java.sql.Connection getConnection();
>
> }
>
> public class DataAdaptorFactory {
>
> public static DataAdaptor getDataAdaptor() {
> //lookup data adaptor implementation class
> //in DataAdaptor.properties file
> //do a class for name on that implemenation class
> //return that class.
> }
> }
>
> DataAdaptor.properties:
> dataAdaptor=mypackage.MySqlDataAdaptor
>
> public class MySqlDataAdaptor implements DataAdaptor {
>
> public java.sql.Connection getConnection() {
> //mysql specific stuff to get a connection
> }
> }
>
> public class EmployeeDataObject {
> public EmployeeList retrieve(String fields, String filters) {
> DataAdaptor data = DataAdaptorFactory.getDataAdaptor();
> Connection conn = data.getConnection();
> //execute a query based on the fields and filters passed in
> //transform the results to an 'EmployeeList' collection
> }
> }
>
>
> 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]>
>
>
>
> 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]>
