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