Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 34098 invoked from network); 4 Jan 2010 23:30:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Jan 2010 23:30:12 -0000 Received: (qmail 93026 invoked by uid 500); 4 Jan 2010 23:30:11 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 92978 invoked by uid 500); 4 Jan 2010 23:30:11 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 92970 invoked by uid 99); 4 Jan 2010 23:30:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jan 2010 23:30:11 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jan 2010 23:30:02 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1NRwMn-0007xu-FB for user-java@ibatis.apache.org; Mon, 04 Jan 2010 15:29:41 -0800 Message-ID: <27020976.post@talk.nabble.com> Date: Mon, 4 Jan 2010 15:29:41 -0800 (PST) From: Dan Forward To: user-java@ibatis.apache.org Subject: Re: Mapping a Complex Object In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: dan-nabble@forwardhome.com References: <26961927.post@talk.nabble.com> <4B3ACB48.6000303@burntmail.com> <26970785.post@talk.nabble.com> <4B3C3F62.1040506@burntmail.com> <26997280.post@talk.nabble.com> <4B4021CF.7040200@burntmail.com> <27002148.post@talk.nabble.com> <16178eb11001030751x76f55fbdy5951c38e7519b033@mail.gmail.com> <27019604.post@talk.nabble.com> <2f55db671001041344m7590966dg8dae5c2c16ccc77f@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org 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 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-unsubscribe@ibatis.apache.org For additional commands, e-mail: user-java-help@ibatis.apache.org