ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Forward <dan-nab...@forwardhome.com>
Subject Re: Mapping a Complex Object
Date Mon, 04 Jan 2010 23:05:29 GMT


nmaves wrote:
> 
> Dan,
> 
> In short I think the largest issue I have seen with your thought process
> is
> over design issues.  You reference that you want to use Guice but the
> Guice
> team would disagree with your approach to use static factory methods
> instead
> of constructors.  DI frameworks like Guice have almost removed all factory
> methods in our entire codebase, which makes testing a dream.  You choice
> to
> wrap every simple object into a Class is something I have never seen done
> all my years of development.  I think you are breaking basic OO design if
> your EmailAddress class does nothing more then act like a String.  If your
> object is a String the use it.  You only reference one Java book like it
> is
> the bible.  The first edition of that book was almost 10 years ago.  Many
> views have changed and you might look into a few of these new ideas.
> 
> These are my personal thoughts which are not meant to offend.  Your
> problems
> would be easily solved with a reduction of design complications that you
> have committed to.
> 
> Nathan
> 

The design I presented is one that I have used and liked for many years. I
started a successful startup company seven years ago with this approach.
Now, with a new startup I would like to use more of the existing frameworks,
but am finding that they do not accommodate this technique very well.

My EmailAddress class is more than a String. It validates that it is in the
proper format when it is constructed. When sending an email, I know I have a
valid email address when the parameter is an EmailAddress and not a String.
It is the same principle as the java.net.URL class and the java.io.File
class. They are both just a String underneath, but additional type safety
and validation occurs when these custom classes are used.

The second edition of Effective Java was published in 2006. The author wrote
the Java Collections classes when he worked for Sun and he is now the Chief
Java Architect at Google. It is one of the best books on Java development I
have read.

I am okay with writing custom handlers for my classes. It was also pretty
simple to accommodate the static factories by writing my own ObjectFactory.
My main suggestion for iBATIS would be to allow association elements and
primitives under the constructor element in a result map, like this:

<resultMap type="User" id="userMap">
	<constructor>
		<idArg column="id" javaType="UserID" typeHandler="UserIDHandler"/>
		<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>
		<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>
</resultMap>

-- 
View this message in context: http://old.nabble.com/Mapping-a-Complex-Object-tp26961927p27020853.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.


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


Mime
View raw message