Your DTO and BO should be memento compatible. If your BO's getters return instance data directly, and there is no private instance data that doesn't have a getter, then a DTO is extraneous, and you can just use a simple struct. However, that's usually not the case, and if any of your BOs require DTOs, then all your BOs should use DTOs for consistency across your application.
You could call the getters on the BO from your controller, and assemble a struct containing their return values to pass to the view, but then you're coupling your controller to you BO to a pretty high degree. If you add a new field to your BO, then you have to go change the controller code every place you create that struct. If you use a DTO, then you just have to change it one place. DTOs can also be used to send data the other way as well. Say you have a form submission. You need to validate it syntactially (make sure numbers are numbers, dates are dates, etc.), which is a UI/presentation concern. You can create a DTO for grouping all that data while you process it, and then when you need to create a BO (only if the data is valid), you can use the DTO from view -> model. You can also send objects between separate models. Say you have two applications on a shared server. They are basically stand-alone, but they share a user database. You want to allow users who are logged into app1 to switch to app2 without having to log in again. One option is to simulate a login form submission from app1 to app2 with the user's credentials, but that's just asking for trouble. A better option is a CFC in the server scope which manages authenticated sessions for both apps, and uses DTOs to pass users back and forth between the apps. Each app might have a different concept of a user, and therefore a different BO, but they can communicate freely via their DTOs, which are memento compatible. They can also use the same DAOs for the same reason. There are certianly better examples, but the point is that DTOs are really helpful down the road, and they aren't much of a cost initially, but if you start with structs, switching to DTOs is a pain in the ass (don't ask how I know ;), so it's better to start with them. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Gabriel Roffman > Sent: Tuesday, December 09, 2003 4:42 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] do you return an obj or a memento from > your manager? > > > The "ideal" solution is to use a data transfer object (DTO). It's a > > lightweight version of your BO, that only has getter > methods. It takes a > BO > > memento upon construction, but provides no way to modify > it, so it can be > > safely passed to the view components. The downside here is > that you have > to > > duplicate the getter methods in the BO and the DTO, but > that's a small > price > > to pay to keep the encapsulation unbroken. I think you > might even be able > > to dynamically construct a DTO with the BO's getter methods > (assuming > CFCs, > > of course), and save yourself the duplication, but I'm not > sure about > that. > > If your DTO is so lightweight, then why bother having any > getter methods. > It would seem that your controller or data manager could call any > calculating functions in your BO and send the results as part of the > structure to your view. I certainly understand encapsulating > your BO's, but > is there really any need for a DTO being sent to a view? > > > ---------------------------------------------------------- > 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]
