You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jerry Jalenak <Je...@LABONE.com> on 2002/10/31 22:12:22 UTC
[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....
TIA,
Jerry Jalenak
Web Publishing
LabOne, Inc.
10101 Renner Blvd.
Lenexa, KS 66219
(913) 577-1496
jerry.jalenak@labone.com
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
Posted by "V. Cekvenich" <vi...@users.sourceforge.net>.
Or don't use ResultSet at all, for anything.
Use the RowSet; there is a jxUtil.sf.net RowSet that is disconnected
from the DB that I use.
Similar to
http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.html
2nd choice: is SQL-commons dynabeans.
OT: The basicDAO will have 2 implementations of out the box, RowSet
which I love, and SQL-commons dynabeans. The basicPortal will demo how
you can change the persitance layer w/o impact on beans and do so in
high performance! (OTOT: I would love to have gone against the
ServerSide .NET, I am sure I would run circles around net using DAO and
RowSet).
.V
Craig R. McClanahan wrote:
>
> 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>
Re: [Best Practices] Use of Map as ValueObject
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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>