RE: [Best Practices] Use of Map as ValueObject

[Jerry Jalenak <Je...@LABONE.com>]

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 ?

Jerry

> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Thursday, October 31, 2002 4:05 PM
> To: Struts Users Mailing List
> Subject: Re: [Best Practices] Use of Map as ValueObject
> 
> 
> 
> 
> On Thu, 31 Oct 2002, Jerry Jalenak wrote:
> 
> > Date: Thu, 31 Oct 2002 15:12:22 -0600
> > From: Jerry Jalenak <Je...@LABONE.com>
> > Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> > To: "'struts-user@jakarta.apache.org'" 
> <st...@jakarta.apache.org>
> > Subject: [Best Practices] Use of Map as ValueObject
> >
> > During a conversation with one of my programmers today, I 
> mentioned that I
> > had begun using Maps instead of a ValueObject bean to pass 
> basic data
> > elements between my Action, Business Logic, and DAO levels. 
>  Coming back up
> > from a DAO I've tended to pass the ResultSet (or void) back 
> to my Business
> > Logic.  In my Business Logic I instantiate a bean, populate 
> it with the data
> > from the ResultSet, and pass it back to my Action.  The 
> Action can then
> > store it in the request/session (as needed), and then forward to the
> > appropriate JSP.  I was asked what the advantages were to 
> this approach, and
> > aside from not having to write ValueObject beans, I can't 
> come up with a
> > good answer.  My question to the list then is this - Is 
> this an appropriate
> > approach to passing simple data elements between 
> application layers?  Is it
> > better to write ValueObject beans?  If so, why?
> >
> > I'm open to comments on this, as we are trying to 
> standardize on how we pass
> > data around....
> >
> 
> One consideration about Maps is that you give up type safety, 
> because the
> values in the Map can be anything.  The availability of the 
> DynaBean APIs
> (as opposed to the specific way Struts uses them in 
> DynaActionForms) gives
> you an opportunity to have type safety without having to create value
> object classes.
> 
> An example of this technique can be found in the nightly builds of
> commons-beanutils (which is also in any recent nightly build 
> of Struts).
> Check out the ResultSetDynaClass class, which (as the name 
> implies) wraps
> dynabean access around a result set, with the data types of 
> the properties
> being determined based on the JDBC metadata about the result 
> set or row
> set.  Javadocs are at:
> 
>   http://jakarta.apache.org/commons/beanutils/api/
> 
> I would share the same concern about passing result sets from 
> your DAOs
> back up to the business logic, because you have to keep the result set
> (and therefore the current statement) open while you're 
> processing it.  In
> many scenarios, there is no good time to clean up.  You could 
> still use
> something like ResultSetDynaClass around a disconnected RowSet
> implementation, though.
> 
> Craig
> 
> 
> --
> To unsubscribe, e-mail:   
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [Best Practices] Use of Map as ValueObject

["Craig R. McClanahan" <cr...@apache.org>]

On Fri, 1 Nov 2002, Jerry Jalenak wrote:

> Date: Fri, 1 Nov 2002 11:14:55 -0600
> From: Jerry Jalenak <Je...@LABONE.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: 'Struts Users Mailing List' <st...@jakarta.apache.org>
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>