I have something similar, but with another layer on top of it. My app has an interesting requirement in that the data can potentially be split across multiple physical databases and/or file groups (but need not be). Further, the division can be modified after deployment.
To handle that, I have an extra layer that maps a "sub-schema name" to a DataSource name. This way, my business layer asks for a database provider by sub-schema name, and from that, it can obtain connections for the appropriate database without having to know anything about which physical database it is actually using. If the location of part of the database changes, all I have to modify is the sub-schema name <-> data source name mapping - the business layer doesn't care. This may be more than anyone else needs, but I just thought I'd throw the idea out there... -- Martin Cooper > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 06, 2002 2:27 PM > To: Struts Users Mailing List > Subject: Re: Alternative Datsource Hot-potatoing... > > > As mentioned elsewhere today, I've been using this ConnectionAdaptor: > > http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/scaf fold/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-resou > rces-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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
