在使用Web服务的客户端正在查找当前与数据库实体一对一匹配的数据的情况下（即GetAccount，GetTransactions）;我们仍然希望使用数据传输对象（dto）将两者分离，以便在需要时允许数据库实体进行更改，而不会在整个系统中波及？如果是这样，从消费的角度来看，我们不希望直接基于数据传输对象的客户端模型。出于与我们首先使用DTO相同的原因，我们希望将从Web服务返回的内容转换为本地模型吗？我有这个权利吗？
答案 0 :(得分：2)
DTO匹配您要传输的数据的形状。如果它与底层数据模型匹配那么它就是它，但那是by。您可能会在某些时候更改基础数据模型的形状，但DTO不会更改。
此外，DTO是Web服务传递给客户端的内容。如果您在服务器上定义了数据模型，那么您不希望分布式客户端必须知道该数据模型。
最后，您的实体类可能包含其他逻辑，而DTO只是暴露数据的属性而不是其他内容。
答案 1 :(得分：0)
您的应用程序可以有许多概念层。数据层，业务层，服务层，表示层等等。每个都有一个具有输入和输出的特定功能。目标是如何设计松散耦合的系统（即，事物不会彼此严重依赖，因此任何变化都是孤立的，影响最小）。您希望最大化可维护性，提高重用率并最大限度地提高速度。诀窍是降低复杂性，但建立一些基本的分离，使您可以根据需要轻松地移动设计。请记住YAGNI！你不需要GONNA！人们倾向于寻找并设计最复杂的架构来解决他们永远不会遇到的问题！我听过的次数“我们有一个单独的数据层，所以我们可以在将来换掉数据库”......但我从来没有见过它！一个简单的存储库模式可以工作。
根据之前的海报，您希望将数据库中的数据（在物理模型中）转换为概念模型。然后，任何客户都将使用您的概念模型。我会在您的应用程序代码从您的数据层检索数据库中的数据时立即执行此操作。这可确保对数据库所做的任何更改都与应用程序的其余部分隔离。因此，您不必开始更改用户界面，因为您已更改数据库字段的名称。您只需更新数据层。
如果选择Entity Framework作为数据访问策略，它会将您的数据库映射到概念模型。如果要将其他数据对象从一种类型转换为另一种类型，请查看AutoMapper等技术。您可以将实体框架POCO映射到服务合同（XSD）。从客户端的角度来看，“你可以”编写一个调用Web服务的客户端代理，将返回的服务契约映射到一个漂亮的共享概念对象模型。
保持简单。保持重复使用和简洁是您选择的核心。如果您开始在客户端对象中看到数据库列名称，则需要开始考虑在解决方案的早期版本中添加一些抽象，以使应用程序与更改隔离。