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>
