Your BOs are more than just encapsulated data. As the name suggests, they contain business rules about the object as well as the state. They are a complete image of the real-life business entity, not just the information about it, but also the things it knows.
DTOs are used to pass the state of a BO around in a format that is readable, but immutable. For instance, you don't want to pass a BO to an external system, because you don't want them calling setters and stuff on your object. So you pass a DTO, which only has getters for extracting the data. You can do the same thing to a persistance framework, or any other "thing" that needs to be able to get data about a BO, but shouldn't be allowed to change it. DTOs are usually very short-lived, and are constructed repeatedly, so it's also important that they are as lightweight as possible for efficiency reasons. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Justin Balog > Sent: Thursday, October 16, 2003 7:26 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [CFCDev] Memento (Acronym Clarification) > > > > That makes sense, and I understand it much better now. The reason I began > reading through the archives was to research in order to better understand > your post concerning BOs and DTOs relating to my question about the > modelCFC. BOs are objects like person, address, warrant, etc. Basic > mechanisms for encapsulating instance data and passing it around. > DTOs are > Data Transfer Objects used to persist data? Am I reading that > correctly? > > Thanks again, > > Justin ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word '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]
