In which we discuss data transfer objects

Where do we begin?

   A data transfer object is a dumb object that just holds properties and values that can be used to move things back and forth.  A perfect example of this is a class simply written to hold data passed to of you in the new ASP.net MVC framework.  Also, a data transfer object may be something that is sent internally to a class to help move around data in a structured format.

   I have found, through watching videos and reading code from people such as Jean Paul Boodhoo (JP) that data transfer objects are really just that, a dumb object to hold data and is stored in their own project.  Furthermore, these objects don't know anything about the data they're holding or any other context of the application other than their own internal variables.
   The question I have come across while writing multiple applications is where do I keep the logic?  I want to maintain to the single responsibility principle where my classes only have one reason to change, and that means they must maintain quite a bit of functionality when dealing with these objects.  When would somebody put logic in a data transfer object?

    In the next few iterations of my software project than writing, project Troy, I will begin making a difference between the logic in data transfer objects and the logic in such classes that I like to call "engines."

Just random thoughts on a random evening.