ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Huy <huym...@swiftdsl.com.au>
Subject Flexible ResultMaps (Again)
Date Sat, 05 Feb 2005 03:28:00 GMT
Hi,

I know I threw this question out before but I've just had a few more 
thoughts about this.

The idea was to have a single resultmap for an entire table/domain class 
mapping which can be  reused in multiple <select> statements without the 
select statement providing every column specified in the result map.

I love result maps except for this fact. I love it more then the 
automapping (i.e select column as property) because it keeps my sql 
super clean. I hope they are never removed.

My thoughts are as follows:

1. I can't think of a reason why we have to tie the resultmap stiffly to 
the <select> statement in terms of the column mapping. I always just 
check my select statement to see what columns it returns and from that I 
know I always map particular columns to particular properties.

2. In my DAOs I call particular select statements (I don't even think 
about resultmaps) so again I check my select statements for what I can 
expect. If I were to change the select statement, having the resultmap 
tied closely would not help me much, because I would just change both. 
My unit test would help me ensure that I have not missed something in my 
select statements. I would not rely on the resultmaps to ensure 
consistency. In fact, having to write out multiple resultmaps for the 
same domain object is more error prone and confusing (if I use extends 
alot).

If someone can help me understand the reason why we have to have this 
close relationship between resultmaps and <select> statements then I can 
rest easy that what I'm currently doing is in fact the best way.

I've survived without this (and will continue to do so without it), but 
I'm greedy and I'd like to have my  cake with icing on top :-)

Thanks and Best Regards,

Huy




Mime
View raw message