blocks|key|329857|text|有些项目的所有数据都有两次。一次作为域对象，一次作为数据传输对象。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|329858|这种复制有巨大的成本，所以架构需要从这种分离中获得巨大的好处，才值得这样做。|329859|entityMap^0|0|D|0|2|8|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

Some projects have all data twice. Once as domain objects, and once as data transfer objects. 

This duplication has a huge cost, so the architecture needs to get a huge benefit from this separation to be worth it.

blocks|key|3089139|text|DTO不是反模式。当您通过网络发送一些数据(例如，发送到Ajax调用中的网页)时，您希望确保只发送目的地将使用的数据来节省带宽。此外，表示层的数据格式通常与本机业务对象的格式略有不同，这也很方便。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3089140|我知道这是一个面向Java语言的问题，但是在.NET语言中，匿名类型、序列化和LINQ允许动态构造DTO，这减少了使用它们的设置和开销。|3089141|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

DTOs are not an anti-pattern. When you're sending some data across the wire (say, to an web page in an Ajax call), you want to be sure that you conserve bandwidth by only sending data that the destination will use. Also, often it is convenient for the presentation layer to have the data in a slightly different format than a native business object.

I know this is a Java-oriented question, but in .NET languages anonymous types, serialization, and LINQ allow DTOs to be constructed on-the-fly, which reduces the setup and overhead of using them.

blocks|key|331002|text|DTO+an+AntiPattern+in+EJB+3.0说：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|331003|331004|在EJB3.0之前的EJB规范中，实体Beans的重量级特性导致了设计模式的使用，如数据传输对象(DTO)。DTO成为轻量级对象(首先应该是实体bean本身)，用于跨层发送数据……现在EJB3.0规范使实体bean模型与普通Java对象(POJO)相同。使用这个新的POJO模型，您将不再需要为每个实体或一组实体创建DTO+...如果您想跨层发送EJB3.0实体，请让它们只实现java.io.Serialiazable|blockquote|331005|331006|entityMap|0|LINK|mutability|MUTABLE|url|http://www.jroller.com/raghukodali/entry/dto_an_antipattern_in_ejb^0|0|T|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|V|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

<a href="http://www.jroller.com/raghukodali/entry/dto_an_antipattern_in_ejb" rel="noreferrer">DTO an AntiPattern in EJB 3.0</a> says:

<blockquote>
 The heavy weight nature of Entity
 Beans in EJB specifications prior to
 EJB 3.0, resulted in the usage of
 design patterns like Data Transfer
 Objects (DTO). DTOs became the
 lightweight objects (which should have
 been the entity beans themselves in
 the first place), used for sending the
 data across the tiers... now EJB 3.0
 spec makes the Entity bean model same
 as Plain old Java object (POJO). With
 this new POJO model, you will no
 longer need to create a DTO for each
 entity or for a set of entities... If
 you want to send the EJB 3.0 entities
 across the tier make them just
 implement java.io.Serialiazable
</blockquote>

blocks|key|328373|text|OO纯化论者会说DTO是反模式的，因为对象变成了数据表表示，而不是真正的域对象。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|328374|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

OO purists would say that DTO is anti-pattern because objects become data table representations instead of real domain objects.

blocks|key|3089119|text|我不认为DTO本身是一种反模式，但是有一些反模式与DTO的使用相关联。Bill+Dudney以DTO爆炸为例：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3089120|http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf|offset|length|3089121|这里还提到了一些DTO的滥用：|3089122|http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/|3089123|它们起源于三层系统(通常使用EJB作为技术)作为在各层之间传递数据的方法。大多数基于Spring等框架的现代Java系统采用另一种简化的视图，使用POJO作为域对象(通常使用JPA等注释)在单层中...这里不需要使用DTO。|3089124|entityMap|0|LINK|mutability|MUTABLE|url|1^0|0|0|1Y|0|0|0|0|23|1|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@$D|V|E|W|1|X]]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@$D|10|E|11|1|12]]|A|$]]|$1|J|3|K|5|6|7|13|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|C]]|S|$5|O|P|Q|A|$R|I]]]]

I don't think DTOs are an anti-pattern per se, but there are antipatterns associated with the use of DTOs. Bill Dudney refers to DTO explosion as an example:

<a href="http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf" rel="noreferrer">http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf</a>

There are also a number of abuses of DTOs mentioned here:

<a href="http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/" rel="noreferrer">http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/</a>

They originated because of three tier systems (typically using EJB as technology) as a means to pass data between tiers. Most modern day Java systems based on frameworks such as Spring take a alternative simplified view using POJOs as domain objects (often annotated with JPA etc...) in a single tier... The use of DTOs here is unnecessary.

blocks|key|328376|text|一些人认为DTO是一种反模式，因为它们可能被滥用。它们通常在不应该/不需要的时候使用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|328377|This+article含糊地描述了一些滥用行为。|offset|length|328378|entityMap|0|LINK|mutability|MUTABLE|url|http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/^0|0|0|C|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Some consider DTOs an anti-pattern due to their possible abuses. They're often used when they shouldn't be/don't need to be.

<a href="http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/" rel="nofollow noreferrer">This article</a> vaguely describes some abuses.

blocks|key|329861|text|如果您正在构建一个分布式系统，那么DTO肯定不是反模式。并不是每个人都会在这种意义上开发，但如果你有一个(例如)开放社交应用程序都运行在JavaScript上。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|329862|它会将大量数据发布到你的API中。然后将其反序列化为某种形式的对象，通常是DTO/Request对象。然后，在将其转换为模型对象之前，可以对其进行验证，以确保输入的数据是正确的。|329863|在我看来，它被视为一种反模式，因为它被误用了。如果您不是在构建分布式系统，那么您很可能不需要它们。|329864|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If you're building a distributed system, then DTOs are certainly not an anti pattern. Not everyone will develop in that sense, but if you have a (for example) Open Social app all running off JavaScript. 

It will post a load of data to your API. This is then deserialized into some form of object, typically a DTO/Request object. This can then be validated to ensure the data entered is correct before being converted into a model object. 

In my opinion, it's seen as an anti-pattern because it's mis-used. If you're not build a distributed system, chances are you don't need them.

blocks|key|3089239|text|问题不应该是“为什么”，而应该是"when“。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3089240|当使用它的唯一结果是成本更高的-运行时或维护时，它肯定是反模式。我从事的项目具有数百个与数据库实体类相同的DTO。每次你想添加一个字段，你需要添加id四次-到DTO，到实体，从DTO到域类或实体的转换，反向转换，...你忘记了一些地方和数据变得不一致。|3089241|当你真的需要领域类的不同表示时，它就是而不是反模式--更扁平、更丰富、更窄……|3089242|就我个人而言，我从域类开始，在正确的地方进行适当的检查，并将其传递给其他人。我可以注释和/或添加一些“助手”类来进行映射，到数据库，到JSON或XML等序列化格式……如果我觉得有必要的话，我总是可以把一个班分成两个班。|3089243|这与你的观点有关--我更喜欢把一个域对象看作是扮演不同角色的单个对象，而不是从彼此创建的多个对象。如果一个对象唯一的角色是传输数据，那么它就是DTO。|3089244|entityMap^0|H|4|0|S|2Q|0|0|9|J|K|0|0|31|0|0|23|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|13|8|@$9|14|A|15|B|C]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|O|$]]

The question should not be "why", but "when".

Definitively it's anti-pattern when only result of using it is higher cost - run-time or maintenance. I worked on projects having hundreds of DTOs identical to database entity classes. Each time you wanted to add a single field you ad to add id like four times - to DTO, to entity, to conversion from DTO to domain classes or entities, the inverse conversion, ... You forgot some of the places and data got inconsistent. 

It's not anti-pattern when you really need different representation of domain classes - more flat, more rich, more narrow, ... 

Personally I start with domain class and pass it around, with proper check in the right places. I can annotate and/or add some "helper" classes to make mappings, to database, to serialization formats like JSON or XML ... I can always split a class to two if I feel the need.

It's about your point of view - I prefer to look at a domain object as a single object playing various roles, instead of multiple objects created from each other. If the only role an object has is transporting data, then it's DTO.

blocks|key|3302126|text|当所有的域对象都加载了相关的对象EAGERly时，DTO就成了必需的，而不是一种反模式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3302127|如果你不做DTO，你将有不必要的对象从你的业务层转移到你的客户端/web层。|3302128|来限制这种情况下的开销，而不是传输DTO。|3302129|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

DTO becomes a necessity and not an ANTI-PATTERN when you have all your domain objects load associated objects EAGERly.

If you don't make DTOs, you will have unnecessary transferred objects from your business layer to your client/web layer.

To limit overhead for this case, rather transfer DTOs.

blocks|key|3089101|text|我认为人们的意思是，如果您将所有远程对象都实现为DTO，那么它可能是一种反模式。DTO仅仅是一组属性，如果你有大的对象，你总是会转移所有的属性，即使你不需要或不使用它们。在后一种情况下，最好使用代理模式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3089102|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think the people mean it could be an anti-pattern if you implement all remote objects as DTOs. A DTO is merely just a set of attributes and if you have big objects you would always transfer all the attributes even if you do not need or use them. In the latter case prefer using a Proxy pattern.

blocks|key|328402|text|Data+Transfer+Object的目的是存储来自不同来源的数据，然后立即将其传输到数据库(或Remote+Facade)中。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|328403|但是，DTO模式违反了+，因为DTO不仅存储数据，而且还将数据从数据库/外观传输到数据库/外观。|328404|将数据对象与业务对象分离的需要并不是反模式，因为无论如何都可能需要使用separate+the+database+layer。|328405|您应该使用Aggregate和Repository模式来代替DTO，该模式将对象集合(Aggregate)和数据传输(Repository)分开。|328406|要传输一组对象，您可以使用Unit+Of+Work模式，该模式包含一组存储库和一个事务上下文；以便在事务中单独传输聚合中的每个对象。|328407|entityMap|0|LINK|mutability|MUTABLE|url|http://martinfowler.com/eaaCatalog/dataTransferObject.html|1|http://martinfowler.com/eaaCatalog/remoteFacade.html|2|https://rads.stackoverflow.com/amzn/click/com/0321125215|3|http://martinfowler.com/bliki/DDD_Aggregate.html|4|http://martinfowler.com/eaaCatalog/repository.html|5|http://martinfowler.com/eaaCatalog/unitOfWork.html^0|0|K|0|1E|D|1|0|0|Z|R|2|0|17|9|3|1N|A|4|0|D|C|5|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@$A|14|B|15|1|16]|$A|17|B|18|1|19]]|C|$]]|$1|D|3|E|5|6|7|1A|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1B|8|@]|9|@$A|1C|B|1D|1|1E]]|C|$]]|$1|H|3|I|5|6|7|1F|8|@]|9|@$A|1G|B|1H|1|1I]|$A|1J|B|1K|1|1L]]|C|$]]|$1|J|3|K|5|6|7|1M|8|@]|9|@$A|1N|B|1O|1|1P]]|C|$]]|$1|L|3|-4|5|6|7|1Q|8|@]|9|@]|C|$]]]|M|$N|$5|O|P|Q|C|$R|S]]|T|$5|O|P|Q|C|$R|U]]|V|$5|O|P|Q|C|$R|W]]|X|$5|O|P|Q|C|$R|Y]]|Z|$5|O|P|Q|C|$R|10]]|11|$5|O|P|Q|C|$R|12]]]]

The intention of a <a href="http://martinfowler.com/eaaCatalog/dataTransferObject.html" rel="nofollow noreferrer">Data Transfer Object</a> is to store data from different sources and then transfer it into a database (or <a href="http://martinfowler.com/eaaCatalog/remoteFacade.html" rel="nofollow noreferrer">Remote Facade</a>) at once. 

However, the DTO pattern violates the <a href="http://www.objectmentor.com/resources/articles/srp.pdf" rel="nofollow noreferrer">Single Responsibility Principle</a>, since the DTO not only stores data, but also transfers it from or to the database/facade. 

The need to separate data objects from business objects is not an antipattern, since it is probably required to <a href="https://rads.stackoverflow.com/amzn/click/com/0321125215" rel="nofollow noreferrer" rel="nofollow noreferrer">separate the database layer</a> anyway. 

Instead of DTOs you should use the Aggregate and Repository Patterns, which separates the collection of objects (<a href="http://martinfowler.com/bliki/DDD_Aggregate.html" rel="nofollow noreferrer">Aggregate</a>) and the data transfer (<a href="http://martinfowler.com/eaaCatalog/repository.html" rel="nofollow noreferrer">Repository</a>). 

To transfer a group of objects you can use the <a href="http://martinfowler.com/eaaCatalog/unitOfWork.html" rel="nofollow noreferrer">Unit Of Work</a> pattern, that holds a set of Repositories and a transaction context; in order to transfer each object in the aggregate separately within the transaction.

I've recently overheard people saying that <a href="https://en.wikipedia.org/wiki/Data_transfer_object" rel="noreferrer">data transfer objects</a> (DTOs) are an anti-pattern. 

Why? What are the alternatives?

Why are data transfer objects (DTOs) an anti-pattern?

数据库

JSON

Java

我最近无意中听到有人说 (DTO)是一种反模式。为什么？有什么替代方案吗？

问为什么数据传输对象(DTO)是反模式？
EN

回答 11

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么数据传输对象(DTO)是反模式？EN

回答 11

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么数据传输对象(DTO)是反模式？
EN