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