ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guy Rouillier <guyr-...@burntmail.com>
Subject Re: Mapping a Complex Object
Date Sun, 03 Jan 2010 04:49:19 GMT
Comments inline.  Overall, you seem to have made this much more 
complicated than it needs to be.  Looking at your database schema from 
your original message, all the table columns are simple strings or 
number, except for the gender enum.  But you've elected to make every 
column a distinct object type.  That is why your solution is more 
complex than you might wish.

Because you've elected to transform every column into a distinct object 
type, you have to tell iBATIS what those object types are.  It can't 
possibly guess at such things.  And that is why you are having to 
specify all the javaType's.  If you would have used simple strings and 
numbers, you would not have to do so.

On 1/2/2010 5:51 PM, Dan Forward wrote:
> Thank you, Guy, you have been a big help!
> This is what I came up with. It works, but not as well as I had hoped.
> <resultMap type="User" id="userMap">
> 	<constructor>
> 		<idArg column="id" javaType="UserID" typeHandler="UserIDHandler"/>
> 		<arg column="gender" javaType="Gender" typeHandler="GenderHandler"/>
> 		<arg column="email" javaType="EmailAddress"
> typeHandler="EmailAddressHandler"/>
> 		<arg column="phone" javaType="TelephoneNumber"
> typeHandler="TelephoneNumberHandler"/>
> 		<arg column="birth_date" javaType="LocalDate"
> typeHandler="LocalDateHandler"/>
> 		<arg column="password_hash" javaType="SHA1" typeHandler="SHA1Handler"/>
> 		<arg column="avatar_id" javaType="StaticFileID"
> typeHandler="StaticFileIDHandler"/>
> 		<arg column="organization_id" javaType="OrganizationID"
> typeHandler="OrganizationIDHandler"/>
> 		<arg column="version" javaType="int"/>
> 	</constructor>
> 	<association property="name" javaType="Name">
> 		<constructor>
> 			<arg column="first_name" javaType="String"/>
> 			<arg column="middle_name" javaType="String"/>
> 			<arg column="last_name" javaType="String"/>
> 			<arg column="suffix" javaType="String"/>
> 		</constructor>
> 	</association>
> </resultMap>
> I was surprised that I had to specify the javaType for every parameter.
> Otherwise, iBATIS treated everything as an Object and could not find a
> corresponding constructor. I then discovered that iBATIS was looking for an
> Integer argument for the version even though I specified the javaType to be
> an int. Finally, I had to remove name from the constructor since constructor
> tags do not support child association tags.

Already discussed the need for all the javaType's.  I don't know about 
the int; I've used them successfully without issue.  I don't understand 
what you mean by "I had to remove name from the constructor"; I don't 
see a column called "name" in your table.

> As a side note, I try to follow the recommendation by Joshua Bloch in
> Effective Java to use static factory methods instead of constructors, so I
> only have private constructors. I used DefaultObjectFactory as a model to
> create my own ObjectFactory that first looks for a matching static factory
> method before looking for a constructor.

I just use JavaBeans instead of trying to do all the data filling from 
the constructor.  iBATIS will use the empty constructor automatically. 
Any particular reason you want to do the data assignments via constructors?

> One of the reasons I chose iBATIS was that Hibernate put too many
> constraints on my domain model. It isn't really a POJO if you say it has to
> have a public constructor, an empty constructor, and setters for every
> property. iBATIS is less strict, but still has some hoops to jump through.
> Wouldn't it be nice to have a persistence layer that transparently
> accommodated the domain model? What if I wanted to use a separate Factory
> class to create my User objects?

Look at page 14 in the documentation.  You can supply your own 

As you've discovered, no persistence layer is perfect.  Unless you write 
your own, every pre-packaged persistence approach will have some 
compromises in order to appeal to a significantly large audience.

If you Google, you'll find several articles comparing Hibernate, JPA and 
iBATIS.  If you are starting from scratch and have complete control over 
both your database implementation and your Java frameworks, then 
something like Hibernate might be appropriate.  In our situation, we 
have a pre-existing, not-well-normalized database; iBATIS removes all 
the grunt work but still allows us complete control over how we access 
our data.

Guy Rouillier

To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org

View raw message