什么是领域模型？为什么它比 .net 中的数据集更受青睐？
我想知道，在作业中我一直在使用数据集。现在，当我开始在这家软件公司工作时，人们正在使用一种称为 DTO（数据传输对象）的东西。领域模型从何而来？到底是什么？
谢谢
I was wondering, in assignments I have been using datasets. Now when I started working in this software company people are using something called DTO - data transfer object. Where does domain model come in ? What is it really ?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
DTO 是简单的数据结构对象，仅用于从数据库传输数据（通常通过 ORM) 并使这些数据可供应用程序的更高层使用。如果 DTO 用于输入适当的域模型层，那么这在架构上是有效的（尽管可能是多余的）。如果您将 DTO 视为域模型层（换句话说，您没有与用户界面分离的域逻辑），那么您将 DTO 用作 贫血域模型，这是一种严重的架构反模式。
DTOs are simple data structure objects that serve only to transfer data out of a database (often via an ORM) and make those data available to higher layers of the application. If a DTO is used to feed into a proper domain model layer, this is architecturally valid (though perhaps redundant). If you treat your DTOs as a domain model layer (in other words, you have no domain logic separate from the user interface), then you are using your DTOs as an anemic domain model, which is a severe architectural anti-pattern.
DTO = 数据传输对象，顾名思义。在系统层之间传输数据的对象。目的通常是调整请求和响应数据，使其适合用例。例如，您可以通过应用程序层中 HR 系统的 CandidateService 请求简历。候选人服务加载跨越不同领域实体的信息：工作经验、教育、个人信件等。为了避免复杂且庞大的响应对象图，我们可以通过构建完全针对客户端（GUI）设计的 DTO 对象来扁平化响应需要。
关于DTO，有很多话要说。但我不想写小说:)但是DTO不属于Domain Model，属于Core。 DTO 在 DDD 中主要被称为应用程序服务与客户端之间通信的工具，特别是当您使用 Web 服务（WCF 等）时。那么 DTO 是将部分域序列化为 Web 服务消息（序列化 DTO）的完美方式。
希望您也可以询问您的同事/同事他们打算通过 DTO 实现什么目标。 DTO 有几个缺点，通常它会给你一个额外的层，这意味着在维护阶段需要做更多的事情......
（现在几乎是一本小说）我仅在有真正的好处时才使用 DTO，那就是当你可以交付一个使用 DTO 进行复杂的响应，完全满足客户的需求。否则，客户端通常需要调用不同的服务或方法来收集足够的信息。
DTO = Data Transfer Object are as it sounds. Object that transfer data between system layers. The purpose is often to adapt the request and response data so it suits the use case. Example can be that you request a CV through a HR system's CandidateService in application layer. The Candidate Service loads information than spans over different domain entities: WorkExperince, Education, Personal Letter etc. To avoid a complex and massive response object graph we can flatten the repsponse by building a DTO object that is exactly design for what the client (GUI) needs.
There are a lot to say about DTO. But I do not want to write a novel :) But DTO do not belong in the Domain Model, in the Core. DTO is mostly refered in DDD as tool for communication between application services to clients, especially if you use web services (WCF etc). Then DTO is a perfect way of serializing part of your domain into a web service message (serialized DTO).
Hopefully you can ask your collegue/co-workers as well what they intended to accomplish with DTO's. There are several drawback with DTO's, usually it gives you an extra layer and that means more to do during maintenance phase...
(almost a novel by now) I use DTO's only when there is a really benefit and thats when you can deliver a complex responses with DTO that matches the clients needs exactly. Otherwise the client usually need to call different services or methods to gather enough information.