Hi, I use the app server's DataSource and build my DAO code based upon the J2EE Blueprints, http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html .
One advantage of using the app server's DataSource, in my case WebSphere, is that connection pooling is handled by the container and easily tweakable by the server admin or deployers. It is relatively easy to setup too. Mark, I wish I knew about the example you posted. I just started looking at it, but the code looks more solid than the example I had and the changes I went with (learning the hard way) are in the code already. "Erik Price" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > Sinclair, Mark wrote: > > Hi All, > > > > Please help I am relatively new to java and even more recently to struts. I > > basically want to know what is the best way (best coding practice & J2EE)to > > connect to and use a DB with struts framework? The approaches that I have > > considered (using my limited experience) are: > > > > 1. I can specify DB in <data-sources> in struts-config and get connection > > etc in Actions to work and e.g. check logon id in LogonAction. However, is > > this the best place for the DB interaction to be coded? All example > > applications that I have seen take this simple approach. This way the DB > > configuration is central and easily managed. > > I think that the reason that sample applications use this approach is > often because the model is not the focus of the sample application (it > has the least to do with Struts out of the three sections of the MVC). > There are two schools of thought that I have heard in my short time > learning about Struts: > > 1. Okay to put model (data access) in the Action > 2. Not okay to do it > > Much easier to put all your model in the Action, and if you never move > away from Struts, maybe it's worth your while. But by doing so you > don't really get a "clean separation" of the model from the controller > so you will get a lot of responses saying "don't do this!". Again, it's > something you have to evaluate for yourself (i.e., are you making a > semi-personal site, a small-business online storefront, or a hospital's > patient-tracking system?). > > > 2. Using a DataServices or DataAccess Layer where the connection to DB and > > all DB interaction is handled. A previous framework that we used had a > > BusinessObject containing a DataObject and called the DataService from the > > BusinessObject. We can do something similar with struts, however each > > DataService e.g. to validate logon ID and password use the UserDS which has > > the connection string inside it. This defeats using struts to centrally > > manage the datasource. Also using this approach cannot read the > > <data-source> from struts-config as no access to the ServletContext outside > > of the Action? Is this correct? > > I think this is why many web containers (including Tomcat) let you > specify JNDI name mappings in their web.xml, because by doing so you do > not need a reference to the ServletContext. You can access the JNDI > service using InitialContext and then supplying the JNDI names. > > By all means, someone should speak up if I am wrong about this. > > > Is it OK to make the connection in the Action and pass it to a parameter to > > the BusinessObject/Bean? > > Possibly, depending on whether you want that BusinessObject/Bean to work > outside of the context where this data could be fetched... kind of an > open ended question. Perhaps you might want to create a Singleton that > is instantiated by a ContextListener? This can be a roll-your-own > alternative to JNDI, by the way. > > > If you have any example code with DB connections etc it would save us > > re-inventing the wheel... :-). > > If you're ready to take an hour to absorb the code base, there is a > pretty good example application that uses the Data Access Object > pattern. The pattern is described at > > <http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.h tml> > > and the sample application, "Adventure Builder", can be found at > > <http://java.sun.com/blueprints/code/adventure/1.0/docs/architecture.html> > > Be sure to follow the links to the actual source code so you can see it > in action. I especially like this particular sample because it shows > how to implement a J2EE application that doesn't use EJBs. (Nearly > every other sample out there seems to do so.) Yet the DAO pattern lets > you sub in EJBs if you decide you want them. > > > Apologies if these are stupid/simple questions! > > I don't think they are either, the problem is that some of them you'll > still have to answer for yourself. > > > > Erik --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
