ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Munat <b...@munat.com>
Subject Re: How to make dao's / vo's more polymorphic
Date Tue, 14 Mar 2006 02:18:46 GMT
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* <bent@munat.com <mailto: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.
> 
>     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* <netsql@roomity.com
>     <mailto:netsql@roomity.com> <mailto: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 ???
>      >      >
>      >      >
>      >
>      >
> 
> 

Mime
View raw message