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]
