ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: Mapping a Complex Object
Date Tue, 05 Jan 2010 00:10:16 GMT
I'm not aware of any O/R mapper that would elegantly handle a micro-typed
domain.  Since frameworks are largely built for commodity application of
common practices, I'm not sure one will be easily found.  This is a unique
design practice, and thus will require a unique solution.

Clinton

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
>
>

Mime
View raw message