Ah. Yes. I *definitely* agree that I would *never* want to use maps for my domain model...
Ack! Talk about anti-OOP....
One of these days I'll get around to trying this: create my domain model with the objects
necessary to accurately represent the domain and with only the methods required for their
appropriate functioning. Then -- to be able to talk to both the db and the outside world
-- add in the ability for the objects (or just certain objects, ala Evans' Aggregate
pattern[1]) to take a map of input and set variables internally (or rack up a list of
validation errors, as appropriate). I would of course need the same sort of behavior to
produce output.... to the UI and to the db.
The interesting thing is that this should actually be completely do-able with iBatis right
now.... I think. Although, isn't there something about maps that hurts performance? That
seems weird to me since there's no introspection involved... just dump the result into a
map. Now, of course, I'd still have the expense of copying the stuff out of the map into
the domain object, but just think how pure my OOP-essence would be! ;-)
b
Clinton Begin wrote:
Fair enough, I agree. You're argument is valid against Sun's design for
JavaBeans and the pattern matching approach of getters/setters -- and
how they are hardly a best OOP practice (I won't get into that OOP
itself isn't necessarily a best practice)....
However, your argument does nothing for or against the use of Maps vs.
classes as domain objects. I will maintain that Maps are a horrible
design choice for a domain model -- horrible.
The solution to the challenges you present is not to use Maps, instead
it is to avoid the use of JavaBeans. Unfortunately, at this time, that
also means no iBATIS (it's a JavaBeans based framework -- poo on us for
listening to Sun).
We're definitely adding support for both constructor injection and
private field based injection of data to address this issue. But until
that time, you're better off with JavaBeans than you are with Maps --
for many, many reasons.
Don't confuse (ab)using maps in Java, with the dynamic programming
capabilities of languages like JavaScript and Ruby.
Cheers,
Clinton
On 3/13/06, * Ben Munat* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Actually, I've long been annoyed with all our frameworks forcing me
to expose all my
domain objects' fields via setters and getters. I've toyed with the
idea of doing all my
selects as maps (and my input from the UI layer too) and giving the
domain objects the
smarts to pick what they need out of the map. Haven't gotten around
to trying it though as
I'm always on a team with other people and they think I'm crazy...
the "bean" paradigm is
very entrenched. However, I'd say that before you go waving around
the "best practices"
ray gun, consider that java beans are hardly best OOP practice.
b
Clinton Begin wrote:
>
> ...and by doing that lose all of the performance, type safety,
context
> and compatibility of a proper domain model. While you're at it,
why not
> dispense with all other best practices as well.
>
> Cheers, ;-)
> Clinton
>
> On 3/13/06, *netsql* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
> You can do that and more including losly coupled by using a
HashMap as
> return type (return ArrayList of Maps from iBatis ) like I
do. No more
> out of sync beans.
>
> .V
>
> Paul Carr wrote:
> >
> > Ideally I'd like all my DAO interfaces to extend a
> BaseDAO
> > and all my
> > value objects to extend a BaseValueObject
> automatically as
> > abator
> > creates them ???
> >
> >
>
>
