struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Tataryn" <craiger...@hotmail.com>
Subject Re: Alternative Datsource Hot-potatoing...
Date Fri, 06 Sep 2002 22:55:11 GMT
<see below>
>From: "Craig R. McClanahan" <craigmcc@apache.org>
>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" <craigmcc@apache.org>
> > >Reply-To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> > >To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > >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 <craiger316@hotmail.com>
> > > > Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > > > To: struts-user@jakarta.apache.org
> > > > 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:struts-user-unsubscribe@jakarta.apache.org>
> > >For additional commands, e-mail:
> > ><mailto:struts-user-help@jakarta.apache.org>
> >
> >
> > Craig W. Tataryn
> > Programmer/Analyst
> > Compuware
> >
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: http://mobile.msn.com
> >
> >
> > --
> > To unsubscribe, e-mail:   
><mailto:struts-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: 
><mailto:struts-user-help@jakarta.apache.org>
> >
> >
>
>
>--
>To unsubscribe, e-mail:   
><mailto:struts-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: 
><mailto:struts-user-help@jakarta.apache.org>


Craig W. Tataryn
Programmer/Analyst
Compuware

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.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