barney, to summarise what you just mentioned about TO's is that it its most simple form a TO can be a struct (maybe even the form scope ?) ...but a more robust solution is to use a separate cfc to represent the TO with a series of getter methods to provide access to the data.
sound about right ? Next question... Can a bean also act as a TO or are they two different things ? In terms of evolution of your app would the order of complexity be struct -> bean (posing as a TO) -> custom built TO ? Pat On Thu, 6 Jan 2005 12:39:03 -0800, Barney Boisvert <[EMAIL PROTECTED]> wrote: > That's definitely the wrong way to look at it. ; ) > > The main goal here is "don't let your business object leave your > business logic layer." > > Simple enough, you can just pass around data directly. However, this > quickly becomes problematic, because you might have 5 or 10 (or 100) > fields for a given object, and that's a lot of little pieces to keep > track of. Also, if you're running across a network (unlikely with CF, > but very likey with enterprise backends), making 100 requests for 100 > separate fields gets really expensive, because there is significant > overhead for the request, even though the data passed around is fairly > trivial. > > Enter the transfer object. > > It provides a way to request a single "thing" from your business logic > layer that includes everything you need to know about the business > object in one package. Easy to keep track of, easy to pass around the > network, and just generally nice and clean. That's why transfer > objects exist. > > In CF, you can also synthesize a TO with a simple struct. The upside > is that it's one less class you have to create and maintain. The > downside is that there's no control over properties (you can set > arbitrary fields in a struct, but not getters in a CFC), and you can't > do logic (for example if you have an 'dateOfBirth' field, but you want > to expose both getDateOfBirth and getAge properties). In general, I'd > recommend using the TO, but you have to make that call based on your > application. > > cheers, > barneyb > > On Thu, 6 Jan 2005 18:24:36 -0200, Marcantonio Silva > <[EMAIL PROTECTED]> wrote: > > > > So, > > > > The TO can be viewed as a security layer, preventing the business logic to > > be accessed from outside ? > > Is this the only reason of TO existence ? > > > > []s > > > > > > > > Marcantonio Silva > > Diretor de Desenvolvimento de Produtos - Navita > > [EMAIL PROTECTED] > > www.navita.com.br > > Tel: +55 11 3055.2004 > > Cel: +55 11 7732.4907 (novo) > > > > -- > Barney Boisvert > [EMAIL PROTECTED] > 360.319.6145 > http://www.barneyb.com/ > > Got Gmail? I have 9 invites. > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
