Data transfer object (DTO), is a design pattern used to transfer data between software application subsystems. DTOs are often used in conjunction with data access objects to retrieve data from a database.
The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behavior except for storage and retrieval of its own data (accessors and mutators). DTOs are simple objects that should not contain any business logic that would require testing.
In a traditional EJB (Enterprise JavaBeans) architecture, DTOs serve dual purposes: first, they work around the problem that entity beans pre-ejb 3.0 are not serializable; second, they implicitly define an assembly phase where all data to be used by the view are fetched and marshalled into the DTOs before returning control to the presentation tier. A third reason of using DTOs could be that certain layers of the application should not be able to access the underlying data access objects, and hence change the data.
Famous quotes containing the words data, transfer and/or object:
“To write it, it took three months; to conceive it three minutes; to collect the data in it—all my life.”
—F. Scott Fitzgerald (1896–1940)
“If it had not been for storytelling, the black family would not have survived. It was the responsibility of the Uncle Remus types to transfer philosophies, attitudes, values, and advice, by way of storytelling using creatures in the woods as symbols.”
—Jackie Torrence (b. 1944)
“Let’s call something a rigid designator if in every possible world it designates the same object, a non-rigid or accidental designator if that is not the case. Of course we don’t require that the objects exist in all possible worlds.... When we think of a property as essential to an object we usually mean that it is true of that object in any case where it would have existed. A rigid designator of a necessary existent can be called strongly rigid.”
—Saul Kripke (b. 1940)