thanks for the clearification of that, I thought had used a DAO to implement the persistence so that itself was the persistence mechanism ----- Original Message ----- From: "Keith Chew" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, January 23, 2002 11:55 AM Subject: RE: Model Persistence Survey
> Hi > > FYI, Data Access Objects (DAOs) is not a persistence mechansim, it's a > design pattern used to encapsulate the mechanism. The mechanism itself can > be JDBC (in the example you have given), Castor JDO, Sun JDO, or any other > O/R mapping tools' API. > > Keith > > -----Original Message----- > From: Francisco Hernandez [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 24 January 2002 8:23 a.m. > To: Struts Users Mailing List > Subject: Re: Model Persistence Survey > > > DAOs are another way to do it, but using a framework is much better imo > > http://java.sun.com/blueprints/code/jps13/src/com/sun/j2ee/blueprints/catalo > g/dao/CatalogDAOImpl.java.html > > > ----- Original Message ----- > From: "Christopher Barham" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > Sent: Wednesday, January 23, 2002 1:51 AM > Subject: Re: Model Persistence Survey > > > > > > Hi, > > I really think that Java Data Objects has a big future... see JSR012: > > http://www.jcp.org/aboutJava/communityprocess/first/jsr012/index.html > > Currently we are evaluating Forte Transparent Persistence, which is a > > physical incarnation of Java Data Objects - see > > http://java.sun.com/products/jdbc/related.html and > > http://access1.sun.com/jdo/ > > The Forte stuff (Transparent Persistence) is detailed here: > > http://www.sun.com/forte/ffj/resources/articles/jdo.html > > > > So far it is working very well - Although I have some qualms about byte > > code enhancement as the mechanism to get the TP activity into your > classes. > > If nothing else, it gives you an 'unknown area' to worry about in your > code > > - For every simple code bug so far we have immediately assumed it is to do > > with the 'magic' of TP messing something up - however, in every case, (so > > far), it has been a simple non-TP coding error that was the root cause - > it > > just took longer to track down :-) > > > > For quick and easy database adhoc code, I have also taken to using > TableGen > > now and then to ease generation of the JDBC aware base classes - it gives > > connection pooling and so on.... It's fairly old, but works nicely with a > > minimum of fuss. The only slight problem was that with Oracle you need to > > explicitly close the Statement in the disconnect method of the generated > > class DatabaseAccess - it took a bit of head scratching to work out where > > the dreaded "too many open cursors" error was coming from :-( > > http://freespace.virgin.net/joe.carter/TableGen/ > > > > Regards > > > > Chris > > > > > > > > > > > > > > > > Struts > > Newsgroup To: > [EMAIL PROTECTED] > > (@Basebeans.c cc: > > om) <struts Subject: Re: Model > Persistence Survey > > > > 22/01/02 > > 23:55 > > Please > > respond to > > "Struts Users > > Mailing List" > > > > > > > > > > > > > > Subject: Re: Model Persistence Survey > > From: Vic Cekvenich <[EMAIL PROTECTED]> > > === > > Oh, yeah, Castor gets votes. > > > > Vic Cekvenich wrote: > > > > > I do not like surveys. But I would like to get a feel for "How are > > > people implementing the model persistence". Sort of a popularity > > > contest. Also if you did not like it, how would you do it next time. > > > So if you would please respond. > > > > > > How do you implement model persistence to a SQL DB. > > > > > > EJB (even for non-midleware needed webapps) > > > > > > Expreso features > > > > > > JDBC ResultSet w/ own base class > > > > > > i Village /Tourge > > > > > > JDBC RowSet > > > ( > > > http://download-west.oracle.com/otndoc/oracle9i/901_doc/java.901/a90211/rows > et.htm > > ) > > > > > > > > > Other? > > > Is there another way? > > > > > > > > > Right now I like RowSet, but what is popular out there? > > > > > > > > > > > > Currious, TIA > > > Vic > > > > > > ps: maybe one day those "hooks" grow on Sturts, so Struts takes a stance > > > on a good aproach for model persistance > > > > > > > > > -- > > 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]> > > > > > -- > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
