Hi,

Can someone tell me if there are any drawbacks to using a HashMap to pass objects from client to server.

for example: in order for my ejb to process a credit card payment it requires a customerVO, creditCardVO and amount.

well, I was thinking I could have the client use a HashMap to pass these objects to the ejb to process a payment,
As oposed to explicitly making these VOs method parameters.

Thank you
A

I prefer to use value object. It is smaller and is self documenting the code.
I use mapped values when a lot of fields in the data are optional and I usually
send only a few.

I seem to recall using a HashMap to pass data (instead of a VO/DTO) as the "Dictionary" pattern and in my belief has several drawbacks:

- No compile time checking. When you pull something out of the returned HashMap, you can never get compile-time validation that what you're casting it to is valid.

- Difficult refactoring. In many IDEs (such as IntelliJ) there are great facilities to refactor a class' method names, variables, etc. This becomes much more difficult when using the dictionary pattern.

- Greater ambiguity for return values. Say in phase 1 of a project, you get back a user object and only use the "getUsername()" method. Then in phase 2 all of a sudden you need to have access to the password attribute. If you have a user object, you know exactly if that value is accessible and how to get it by simply looking at the class. With the HashMap that's not necessarily the case. If you don't have access to the source of the class that generates the HashMap (in this case the EJB), you'll never know what other data attributes are available.

I've personally been the victim of this pattern in several past engagements. I believe it's strength is that it allows the original developer(s) to move a little bit faster because they don't have to code VO/DTO classes. (Even then, I don't think you really save because the keys to retrieving the values from the HashMap are usually in Constant classes, so what are you really saving?) The big drawback (orders of magnitudes bigger than the savings by the original developers) is that new developers that roll on have a much harder time figuring out what's actually in those HashMaps. They tend to have to drill down several layers down to figure out what's going on.

I could rant on forever against this pattern, but I think the above are the crux of the arguments against it :)

Technically Value Objects and Hash Map can be seen similar as 'Place Holders' for data, but when working under a business or domain context the value object hold more value than just a data holder, it also conveys a lot about what is the data about and what is its internal structure.

So just by looking at an interface it will be possible to get a feel of the operation of the method than hiding the details under a HashMap. Also if you make the interface using HashMap, you will need to do more documentation for the funtion as you will now need to communicate what name, what value, how to popilate it, etc.

My recommendation will be to have the interface have Value Object instead of HashMap, if you are worried about having too many parameters, then you could model a wrapper VO based on the context.

thank you all.

I get the point.