什么是“更好”？从服务器查询/保存的方法：DTO 还是 Wcf 数据服务？
从我的角度来看，数据服务及其查询方法在从服务器端域模型查询简单对象图时非常有用。但是，当您想要查询复杂的依赖关系时，我无法从中创建任何好的东西。
经典的 DTO 方法是细粒度的，可以处理所有事情，但缺点是您必须为每种类型的服务器请求创建 Dto 类，这非常耗时，并且必须将 Dto 类型与域实体/业务逻辑同步。
From my perspective, the Data Services and their query approach is useful when querying simple object graphs from your server-side domain model. But when you want to query complex dependencies I couldn't create anything good out of it.
The classic DTO approach is fine-grained and can handle everything, but the downside is that you have to create Dto classes for every type of server-request which is time consuming and you have to synchronize the Dto type with your domain entity/business logic.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
取决于您对“更好”的定义 - 这是否意味着更快的上市速度，或者从长远来看更容易维护应用程序。
手工制作 DTO 将意味着最初的开发工作可能会比使用 WCF 数据服务等工具更长。但是，通过仅公开 DTO，您的应用程序将比 WCF 数据服务与内部域模型更加解耦，因此未来的维护修复可能会更容易、更短。
如果您在初始开发期间有足够的时间和预算，我会倾向于 DTO，因为如果应用程序寿命足够长，就会节省金钱，并且更容易修复/修改。此外，使用 Automapper 等工具可以缓解与域对象和 DTO 之间映射相关的许多痛点。
Depends on your definition of 'better' - whether this is means quicker to market, or an easier to maintain application in the long run.
Hand-crafting DTO's will mean the initial development effort will probably be longer than using a tool such as WCF Data Services. However, by exposing only DTO's your application will be more decoupled from the internal domain model than WCF Data Services, so future maintenance fixes will probably be easier and shorter.
I would tend towards DTO's if you have enough time and budget during initial development as money will be saved if the application lives for long enough, and it will be easier to fix/modify. Also using tools such as Automapper can alleviate many of the pain points associated with mapping between domain objects and DTOs.
另一种方法是使用由 DTO 形式的数据组成的持久视图模型（无映射）。查看 Udi 的 CQRS。
An alternative would be to use a Persistent View Model that consists of the data that is in the form of your DTO(no mapping). Check out CQRS from Udi.