ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Biondi" <Ste...@schemalogic.com>
Subject RE: How to make dao's / vo's more polymorphic
Date Tue, 14 Mar 2006 02:04:49 GMT
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.


From: Clinton Begin [mailto:clinton.begin@gmail.com] 
Sent: Monday, March 13, 2006 5:10 PM
To: user-java@ibatis.apache.org
Subject: Re: How to make dao's / vo's more polymorphic

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.


On 3/13/06, Ben Munat <bent@munat.com> 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. 
	Clinton Begin wrote:
	> ...and by doing that lose all of the performance, type safety,
	> 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* <netsql@roomity.com
<mailto:netsql@roomity.com>> 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 ???
	>      >
	>      >

View raw message