ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Ellis <ellis....@gmail.com>
Subject Re: Mapping a Complex Object
Date Mon, 04 Jan 2010 22:55:11 GMT
Perhaps an alternative to individual classes for each data type would
be to use the builder pattern?  That would avoid having many, many
parameters on the constructor for the User class.  This might help
with the problem of figuring out whether arguments at the call site
match the formal parameters.

At ten parameters, this must start to get a bit fiddly:

  private User(UserID id, Name name, Gender gender, EmailAddress email,
TelephoneNumber phone, LocalDate birthDate, SHA1 passwordHash, StaticFileID
avatarID, OrganizationID organizationID, int version)

I'm not sure the extent to which iBATIS would support using a builder,
specifically  in terms of specifying how to use a builder-like object
to create objects built from a ResultSet.  Probably an ObjectFactory
would work.  If it's not possible, it'd be possible to extend iBATIS
to do so.

My own solution?  Getters and setters on the persistence model
classes, but only getters in the interface that they implement.
Hence, most of the application never sees the setters, and the objects
appear immutable.  I don't claim it's beautiful, but it does the job,
and it's a lot simpler than going 'against the grain'.


2010/1/4 Nathan Maves <nathan.maves@gmail.com>:
> 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
> On Mon, Jan 4, 2010 at 2:27 PM, Dan Forward <dan-nabble@forwardhome.com>
> wrote:
>> Clinton Begin wrote:
>> >
>> > Dan,
>> >
>> > Why should your domain layer bend to the whims of the persistence
>> > layer?  Because you also chose the persistence layer.  Frameworks are
>> > inherently composed of many assumptions and constraints. Despite your
>> > assertions, the design you propose is atypical.
>> >
>> > I'm going to be totally honest with you.  Given the design choices
>> > you've made, iBATIS is the wrong solution for you.  I recommend you
>> > seek another, or write your own.
>> >
>> > Cheers,
>> > Clinton
>> >
>> Thank you, Clinton, for your assessment. I wonder what framework you think
>> would be a better fit? I was prepared to plow forward with iBATIS
>> regardless, simply because it is the most flexible I've found.
>> In my current project, we have total control of the application and
>> database
>> design. Initially we tried a Spring/Hibernate approach, which required
>> empty
>> constructors and setters for every property and could not accommodate
>> things
>> like MySQL enum types. We got pretty far with that approach until the
>> database started running out of connections. When we found a solution to
>> that problem, transactions stopped working. We then hired a
>> Spring/Hibernate
>> expert to check things over and after two weeks still did not have it
>> working. To make a long story short, we wanted to find a simpler solution,
>> one that would allow us better insight into what was going on under the
>> hood. That led us to Guice/iBATIS.
>> The scenario I first presented in this thread is a proof-of-concept. It
>> isn't our real User object, but it encapsulates the toughest problems we
>> faced with Hibernate and follows what I believe are best practices in Java
>> development. Perhaps good coding practices are atypical. :-)
>> In a former project, I wrote a persistence layer that allowed this type of
>> domain programming. However, it is proprietary code for that company and I
>> did not really want to have to start from scratch again if there was a
>> mainstream product that could help us accomplish the same goals. I would
>> rather compromise design principles in the domain layer than try to build
>> a
>> new persistence layer from scratch, as sad as that may be.
>> Thank you for building such a great tool! Despite my moanings, I think you
>> have done an outstanding job with it. If at all possible, I hope I can
>> contribute back to iBATIS and make it better.
>> Sincerely,
>> Dan Forward
>> --
>> View this message in context:
>> http://old.nabble.com/Mapping-a-Complex-Object-tp26961927p27019604.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

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

View raw message