Martin Ellis-6 wrote: > > 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. >
It is funny that you should mention the Builder pattern, because we have started using that pattern on some of our classes. I was reluctant to mention it as I did not want to complicate the discussion. They could easily be accommodated in an ObjectFactory. The only issue I run into is that I cannot pass an association into the "constructor." Only parameters in the constructor element of the result map are passed into the main ObjectFactory method: public Object create(Class type, List<Class> constructorArgTypes, List constructorArgs); [snip] > 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'. > I may need to go that route as well. I just wanted to see if it could be done beautifully first. -- View this message in context: http://old.nabble.com/Mapping-a-Complex-Object-tp26961927p27020976.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
