Quick follow up question. Do initialize the DTO in the BO, or do you initialize the DTO and pass in the BO to populate it. I am guessing its the later?
Justin -----Original Message----- From: Barney Boisvert [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2003 10:55 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] do you return an obj or a memento from your manager? You'd only have one DTO class (CFC file on the file system) per BO, but you can instantiate instances of it from wherever. That's one great thing about encapsulation, the environment an instance is used in is irrelevant. To return to the validation example, chances are your model and/or services aren't going to be involved at all in the initial stages of validation, so there's no need to involve them to get a DTO for you. Just instantiate it directly in your controller, use it, and then if you need to (the object is valid), pass it back to your services/model to do what they will with it (probably use it to initialize a newly instantiated BO, and continue the validation). Another way to think about it is that from the outside, a DTO is pure data. The internal representation might be different (stores birth date, exposes age), but the calling code doesn't know that. If it's pure data, it doesn't belong to any particular tier of your application, because data is used throughout all tiers. If you're persisting to a DB that you interact with directly, you usually don't use a DTO between your model and the persistance layer, but if you're not interfacing with the DB directly, then DTOs are used there too. For the direct DB persistance, you use a DAO, which is in many ways a special kind of DTO, but one that doesn't expose getters, rather exposing SQL statements. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Gabriel Roffman > Sent: Wednesday, December 10, 2003 5:09 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] do you return an obj or a memento from > your manager? > > Forgive my aborted last message. Sometimes Outlook Express > gets away from > me... > > I was trying to say it sounds like a DTO is the contract or interface > between your presentation tier and your services tier. One > question would > be is if you are creating a new object (lets say a User for > simplicity), > would you call your services tier and have it return a blank > DTO which you > would then use your presentation tier's controller to fill in > the blank User > DTO to send it back to the services tier? Or does your > presentation tier > create its own DTO's to send to the services tier? It would > seem that if > your DTO is in fact your contract between the presentation > and services > tier, you would only want to define it in one place. Yes? > > ----- Original Message ----- > From: "Barney Boisvert" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, December 09, 2003 7:59 PM > Subject: RE: [CFCDev] do you return an obj or a memento from > your manager? > > > > 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] > > > > > ---------------------------------------------------------- > 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] ---------------------------------------------------------- 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]
