DTO stands for Data Transfer Object, and that's exactly what it does. Its simply a way to pass a bunch of related data around as a single entity. So instead of 50 form fields, I can pass around a single thing that encapsulates all of it.
The "real" use of DTOs is for remote operations, where the cost for passing two items is larger than for passing one item that is twice the size. For example, if I have to ship two pens to Estonia, i'd be better off using a single box (cost maybe $10), rather than shipping them separately (for $8.50 each). That box is analogous to a DTO. If you're operating locally and there isn't a cost for sending multiple smaller items, then the primariy motivation for DTOs goes away. However, they're still useful for keeping track of stuff. For example, no one wants to create a business method with 50 arguments (lots of typing) and have to pass them all in from your controller (lots more typing). Much easier to wrap them up into a single object and move them around as a single unit. Also makes use that nothing gets lots. DTOs aren't necessarily read only. However, they're usually used that way, because they are a copy of some real object's data.. As soon as they're created, they no longer have any affinity to the real object, so updating the DTO is meaningless. It'd be like Jimbo (from Estonia, who I sent the pens to) removing one of the pens and replacing it with a pencil. I still shipped him two pens, no matter what he does to the contents of the box. Also, DTOs shouldn't have any logic in them. If you want to use a DTO for validation, the validation routine should be external and you pass the DTO in to it. Again, it's not really changing anything, it's just letting you pass around a single thing, rather than 50 separate form fields. So, when should you use a DTO? Whenever you have to pass around a bunch of related data that you don't want to pass around as individual items. It might be from a form submission to your business layer. Maybe from your business layer to a display template (a DTO of user data for a user information form, for example). It might just be from one business component to another, though you'll probably use a full-fledged BO for that task, since you're staying inside the business layer. Also, DTOs can provide abstraction as well. Say I need to generate a user information form. If I pass a bunch of individual fields, then any time one of those fields changes, or I add a new field, I have to go change the list of fields in numerous places. With a DTO, I still have to go change the code in multiple places, but the places will be fewer, and because the DTO is an encapsulated entity, I'll start getting errors, rather than having optional fields being silently ignored. Hopefully that'll make things a little clearer. If you're really interested, I'd highly recommend picking up a book on design patterns. The Gang of Four book is pretty much the de facto standard, though there are myriad others. I haven't done any comparison, but I'm sure there are many others who could do a better job of recommending one or two. cheers, barneyb On Wed, 17 Nov 2004 10:07:32 +1000, Scott Barnes <[EMAIL PROTECTED]> wrote: > Heh, > > I know what you are all thinking "Oh god, not again!... Hasn't Barney > typed a novel on this subject already?" For this I apologise. > > I noticed that Barney mention earlier on, that a DTO can be used from View > --> Model, in that do basic form validation via a DTO, then pass that into > a BO for server-side validation. This struck a chord in many ways with me, > as I was always under the impression a DTO was read only object, so my > question is when you do form submit, do you initialize the DTO with your > form data? part of the initialization process, it goes and does a bunch of > basic hidden validation routines "is this an integer, does this email have > an @ in the middle of it etc", if any fail throw an exception or store in > an error stack for later? > > Is this how DTO's are used in the "form" validation cycle. > > It then also looses me for a moment, where once the DTO is created, its > then transferred into a Bean, a Bean then does further server-side > validation, which then gets handed into a DAO for storage. > > Once again, I *actually* read the archives and I've pieced together > snippets of this, and while I think i understand the concept of a DTO in > CFMX, the more reading I do on the subject, the more I start > second-guessing the concept, so it would be fantastic to have a final > ruling on my interpretation and maybe could be used as a "heres how DTO > works, and an example of WHEN to use it" for others? heh. > > Regards > Scott Barnes -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/blog/ ---------------------------------------------------------- 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 [EMAIL PROTECTED]
