Talk:Data transfer object

Problems

PLEASE! Consider to erase all the article. It´s completly wrong! DTO is used by transfering object in a distribuided system, not to retrieve data from database. —Preceding unsigned comment added by 201.63.222.114 (talk) 17:20, 8 August 2008 (UTC)

The following commentary was moved from the article. It should be reworded before being re-added. RedWolf 18:43, 11 September 2007 (UTC)

The reason that the Sun people changed the name of this pattern from Value Object to Data Transfer Object is that Value Object means something else. See http://c2.com/cgi/wiki?ValueObject or http://www.martinfowler.com/eaaCatalog/valueObject.html The term "Value Object" predates Java, and it has always meant what is in the original wiki and Martin Fowler's book. The Sun people were told not to use that name, and they did anyway, and then they had to change it. DTO is the right name for this pattern, not VO.

-Ralph Johnson

The Java DTO is different from the Fowler (MSDN) DTO. The Folwer DTO is intended to messenging between distributed components; the Java DTO is intended for communicating data received from the database by a DAO. 198.103.211.131 (talk) 18:50, 11 February 2009 (UTC)

---

So, it seems to me that we need a ValueObject page that does NOT redirect to DataTransferObject, and that has a disambig link to DTO. Because ValueObjects already mean something else (namely, an object for which equality is value-equality rather than object identity). That is, the DTO page should say "This concept was once referred to as ValueObject, not to be confused with an earlier use of that term (link)", and the ValueObject page should talk about the Fowler concept, and then say "See also DTO, which was at one point also called ValueObject, even though it's different, dude." I think that chasing down the timelines of these usages would also be helpful in this disambiguation. It's also worth noting that these uses are not completely unrelated (in the sense that they have overlapping extension), which makes telling them apart all the trickier. --jholman (talk) 00:47, 13 August 2009 (UTC)

---

One way to look at Data Transfer Objects is to say that they are a specific kind of Value Objects. The term Value Object is used in a very general fashion to indicate a category of objects which are suitable for passing around by value rather than reference. A consequence of this is that Value Objects are also suitable to be passed across runtime context boundaries such as processes. The ability to distribute them across process boundaries is not (in my view) their differentia specifica.

Data Transfer Objects are Value Objects typically appearing in the context of multi-tier applications, where programming objects optimized to interface with databases (such as JEE entity implementations) need to be converted into objects suitable (a) to be passed to higher tiers (which are almost always in a different process) (b) to be handled in runtime/programming environments often entirely different from the persistency layer where they have been originated (for example, passing JPA entity implementations to the Java Script runtime of web browsers).

Note that there is the closely related category of Value Types appearing in CORBA specifications -- Pdkovacs (talk) 16:22, 27 September 2009 (UTC)

---

This article does not make the difference between a Business Object and a Data transfer object very clear. The business object article says, "a business object differs in that does nothing itself but holds a set of attributes and associations with others weaving a map of players representing the business relations." This sentence is very similar to one in the DTO article: "The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behaviour except for storage and retrieval of its own data (accessors and mutators)."

Is it just me, or are these 2 quotes saying the same thing? Dloose (talk) 19:32, 24 June 2010 (UTC)

The statement "[DTOs] ... work around the problem that entity beans are not serializable" is a straw man. javax.ejb.EntityBean extends java.io.Serializable.

DTO = struct/record. The end.

A DTO is like a struct in C or a record in Pascal.

This seems way more complicated than it needs to be. — Preceding unsigned comment added by 71.154.19.161 (talk) 16:42, 18 August 2016 (UTC)