Oddly enough it's this flexibility that has
made iBATIS indispensible to us. The abstraction of "the data and
behaviors are java domain objects in memory" just doesn't work for us for a
host of reasons. Our tables are big and normalized, we do mainly set-based
operations, work with dynamically defined relations (actual new tables, not
views), rely on covered indexes for performance, use materialized views in many
cases, and these aspects preclude using fully hydrated domain objects,
JavaBean-based or otherwise. Sometimes its better not to ask whether maps are
better than domain objects (which they clearly aren't), but rather whether
domain objects are the right choice at all for your application. Sets and Lists
of Maps "map" to a generic relational model quite well and sometimes offer
a much better solution (no pun intended there) ;-) Using iBATIS to cleanly
structure the SQL has been fantastic, much better than the usual JDBC + SQL
string construction garbage we all see from time to time.
Steve
From: Clinton Begin [mailto:[EMAIL PROTECTED]
Sent: Monday, March 13, 2006 5:10 PM
To: [email protected]
Subject: Re: How to make dao's / vo's more polymorphic
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]> 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]>> 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 ???
> >
> >
>
>
