我正在创建一个全新的应用程序，包括数据库，并且我将首先使用实体框架代码。这还将为服务使用 WCF，从而为不同设备的多个 UI 打开它，并使服务 API 可用于其他未知应用程序。
我在 SO 上的几篇文章中看到了这一点，但我没有看到与 Code First 相关的直接问题或答案，尽管有一些提到 POCO。我将再次提出这个问题，所以这里是 - 我真的需要具有实体框架代码的 DTO，还是我可以将模型用作所有边界的一组通用实体？我真的很想遵循 YAGNI 的思路，所以当我有一张干净的纸时，我想我会先解决这个问题。
谢谢， 保罗·斯佩兰萨
【问题讨论】：
标签： wcf model entity-framework-4.1 dto
这个问题没有明确的答案，这也是你没有找到答案的原因。
您是否要构建提供 CRUD 操作的服务？这通常意味着您的服务将能够按原样返回、插入、更新和删除实体 = 您将始终向所有客户端公开整个实体或实体的单个精确定义的可序列化部分。但是一旦你这样做了，可能值得检查 WCF 数据服务。
您是否要公开与实体一起使用的业务外观？外观将提供真正的业务方法，而不仅仅是 CRUD 操作。这些业务方法将获取一些数据对象并将其分解为包装业务逻辑中的多个实体。在这里，为每个操作使用特定的 DTO 是有意义的。 DTO 将仅传输操作所需的数据，并仅将允许的日期返回给客户端。
非常简单的例子。假设您的实体保留LastModifiedBy 之类的信息。这可能是您想要传递回客户端的信息。在第一个场景中，您有单个可序列化集，因此您将其传递回客户端，客户端将修改后的传递回服务。现在您必须验证客户没有更改该字段，因为他可能没有这样做的权限。您必须对客户无权更改的每个字段执行此操作。在第二种情况下，您的带有更新数据的 DTO 将根本不包含此属性（=您的操作的专用 DTO），因此客户端根本无法向您发送新值。
它可能与您希望如何处理数据的方式以及您的真实逻辑将在何处应用有关。它会在服务上还是在客户端上？您将如何确保客户不会发布无效数据？您想通过逻辑或特定传输对象来限制传递无效数据吗？
【讨论】：
我强烈推荐一个专用的视图模型。
这样做意味着：
但是，对于 WCF 数据服务，当您直接公开实体时，很难忽视能够在基本上一行中编写服务的优势。所以这可能对 WCF/服务器端最有意义。
但在 UI 方面，您“会需要它”。
【讨论】：
我真的需要具有实体框架代码优先的 DTO，还是可以将模型用作所有边界的一组通用实体？
是的，同一组POCOs / entities 可用于所有边界。
但是需要一组映射器/转换器/配置器来使实体适应每一层的一些通用结构。
例如，当实体配置有DataContract 和DataMember 属性时，WCF 能够在不创建任何特殊类的情况下传输域对象的状态。
类似地，当使用Entity Framework fluent mapping api 映射实体时，EF 能够将域对象的状态保存在数据库中，而无需创建任何特殊类。
同样，实体可以通过层基础结构配置为在任何层中使用，而无需创建任何特殊类。
【讨论】：