My business classes typically don't know anything about Datasources or JDBC or any of that. The business classes just hand up a token representing the data access command. The data access routines then use that to return a collection of beans.
But if you're asking DataSources versus Connections, it's because DataSources are advertised to the preferred method now. Given a DataSource, you can always get the connection. My JDBC access routines actually take a connection. The DataSoruce is just a means to an end. -Ted. Craig Tataryn wrote: > Thanks Ted, I'll check it out. But just out of curiosity, why would you > ever want your Business Layer to know about Datasources? > > Craig. > >> From: Ted Husted <[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, 06 Sep 2002 17:27:12 -0400 >> >> As mentioned elsewhere today, I've been using this ConnectionAdaptor: >> >> >http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/scaffold/src/java/org/apache/commons/scaffold/sql/ > >> >> >> But I'd wouldn't mind refactoring it into more of a DataSource >> manager, with the functionality seen in Struts 1.1. The idea being you >> could register several different DataSources, and then have the >> business layer say I want this one, or just give me the default (null) >> one. >> >> -Ted >> >> Craig R. McClanahan wrote: >> >>> >>> 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]> >>> >>> >> >> >> -- >> Ted Husted, Husted dot Com, Fairport NY US >> co-author, Java Web Development with Struts >> Order it today: >> <http://husted.com/struts/book.html> >> >> >> -- >> 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]> > > -- Ted Husted, Husted dot Com, Fairport NY US co-author, Java Web Development with Struts Order it today: <http://husted.com/struts/book.html> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
