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-nab...@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-unsubscr...@ibatis.apache.org > For additional commands, e-mail: user-java-h...@ibatis.apache.org > >
