What does everyone think about CachedRowSet? It appears that it can provide a type of native persistence mechanism in the sense that you can set a command, username, password, etc. directly in the CachedRowSet, then call the appropriate method(s) to retrieve/update data in the database. Is this something reasonable to do in a web app? Are there potential problems with doing this?
Jerry > -----Original Message----- > From: Craig R. McClanahan [mailto:craigmcc@;apache.org] > Sent: Friday, November 01, 2002 11:29 AM > To: Struts Users Mailing List > Subject: RE: [Best Practices] Use of Map as ValueObject > > > > > On Fri, 1 Nov 2002, Jerry Jalenak wrote: > > > Date: Fri, 1 Nov 2002 11:14:55 -0600 > > From: Jerry Jalenak <[EMAIL PROTECTED]> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > > To: 'Struts Users Mailing List' <[EMAIL PROTECTED]> > > Subject: RE: [Best Practices] Use of Map as ValueObject > > > > First, my thanks to David, Derek, Craig, and Vic. Based on > the comments > > I've started revising my approach to passing data elements > around. I think > > I've settled on the use of a disconnected RowSet (maybe > CachedRowSet?) to > > pass data between my business logic and DAO levels. I'm > not sure if the use > > of the ResultSetDynaClass will buy me anything as I'm only > sending a few > > data elements back and forth. The question I have now is where to > > instantiate / destroy these objects so everything gets > cleaned up correctly. > > Thinking it through, I think the following approach is correct - > > > > Business Logic > > instantiate the RowSet object > > call the DAO with the RowSet object > > populate a ValueObject with data from the RowSet > > destroy the RowSet > > > > DAO > > instantiate a ResultSet obect > > get data from the database into the ResultSet > > populate the RowSet object > > close the ResultSet > > > > I'm still not sure of how to pass data into the DAO - i.e. > data that ends up > > in a where clause. I don't think I can pre-populate the > RowSet since I > > don't have any meta-data; short of creating yet another > ValueObject and > > passing it over, I'm not sure of a 'best' way of doing > this... Any comments > > / ideas ? > > > > You could always write a method that takes an entire WHERE clause, but > that is pretty fragile - your business logic would have to be > aware of the > database structure in order to know how to construct this clause, and > that's not a good thing. > > For my DAOs, I like to copy a design pattern from EJB entity > beans (even > when not using EJBs) -- finder methods. Just create a set of > methods that > accept parameters for the things that vary (here assuming that you've > implemented your idea of returning RowSet): > > public RowSet findCustomersById(String customerId); > public RowSet findCustomersByName(String name); > public RowSet findCustomersByCreditStatus(...); > > for the logical lookup criteria that your application needs. > Inside the > finder methods you'll do the grunt work to construct the > appropriate SQL > query (if you're accessing the database directly), or whatever else is > appropriate. You can even replace the underlying > implementation of your > persistence tier without affecting how your business logic operates, > because it's all hidden away in the DAOs. > > > Jerry > > Craig > > > -- > To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org> This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
