-1 for maps after how strongly typed is an object???
+1 for Value Objects If you follow the axiom from Floyd Marinescu
Design custom value objects that wrap arbitrary sets of data as needed by
the client, completely decoupled from the layout of the domain model on the
serverDesign custom value objects that wrap arbitrary sets of data as needed
by the client, completely decoupled from the layout of the domain model on
the serverDesign custom value objects that wrap arbitrary sets of data as
needed by the client, completely decoupled from the layout of the domain
model on the serverDesign custom value objects that wrap arbitrary sets of
data as needed by the client
completely decouple from the layout of the domain model of the server
excerpted from this analysis of ValueObjects,VO Factory available from the
birthplace of HAL at University of Illinois Urbana
http://72.14.207.104/search?q=cache:AgD8-5ccZJ4J:jerry.cs.uiuc.edu/~plop/plop2001/accepted_submissions/PLoP2001/fmarinescu0/PLoP2001_fmarinescu0_0.pdf+%22ValueObject%22+AND+%22Map%22&hl=en
HTH,
Martin-
Design custom value objects that wrap arbitrary sets of data as needed by
the client, completely decoupled from the layout of the domain model on the
server----- Original Message -----
From: "Rick Reumann" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Monday, July 11, 2005 2:56 PM
Subject: Re: Using struts forms as Value Objects: your opinion?
netsql wrote the following on 7/11/2005 2:15 PM:
I think it vastly simplifies to use Maps in places where I used to use
beans. (I even got rid of baseBeans domain how much I loved maps)
Vic I think you sleep with the Map API under your pillow at night or use
it as a Teddy Bear when you sleep:)
I agree Maps will work fine for rapid development, but I like the type
safety of using typed properties in my VOs.
Just as an example, I know we both use iBATIS, under your Map idea, you
could end up with the crap out occuring at the DB level whereas if you use
a typed POJO you'll find the error much sooner. What if in your scenario
you pass in some mangled up String represntation of a Date as your value
in your map and the backend then needs to process that as Date in the DB?
You'll end up with a DB exception. Using normally typed POJOs you won't
have this problem since you'll catch it much sooner when trying to do the
conversion of your String to Date.
The other aspect is just the pure functionality of using a typed VO vs a
Map. For example if you are using a Map to represent an Employee how do
you know what to name the keys? Someone can put in map.put("firstName",
name ).. someone else might put map.put("fName", name ) ? even using
Constants is messy (map.put(Constants.NAME, name).. granted that's better
but now you have to maintain a constants class as well as you Map in place
of a standard POJO?
How do you deal with these issues? How does a developer working on your
code know how to even get the properties out of your Map? I guess he has
to look at some API contract saying put date of birth in the Map as "dob"
not "dateOfBirth." Also, the rapid development using Maps will sure end
up being a drawback when you end up having to work with the Maps. In my
IDE I can get dot completion to work easily but that's not gonig to work
with your Map approach. If I need firstName from employee I can just do
employee(dot)=[pop up of methods]... you're going to get .. employee.
[ get, put, etc Map methods !]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
