It is not the same issue as Java has built-in serialization facilities for persisting data with very little overhead.
Matt Liotta President & CEO Montara Software, Inc. http://www.montarasoftware.com/ 888-408-0900 x901 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of webguy > Sent: Thursday, March 27, 2003 7:52 AM > To: [EMAIL PROTECTED] > Subject: RE: CFC scalability problems (was : RE: [CFCDev] MVCF at > benorama.com) > > > > > The specific situation, as I recall, was where you try to map between a > > pure object representation and a relationship representation - when you > > try to have a CFC which has an instance variable for each column in the > > row. There is quite a bit of overhead involved in marshaling your query > > to and from a series of discrete variables. As noted elsewhere, if you > > try to do this by writing generic code that uses cfproperty to describe > > the instance data, then you're adding a lot of overhead! Of course, you > > don't have to do it this way... > > > This is the same issue the J2ee - ejb implimentions have. The solution in > Java is the > Fast Lane Reader Design Pattern. Read it here : > http://java.sun.com/blueprints/patterns/FastLaneReader.html > > In CFMX just returning a query is a solution. > > WG > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
