最近我听到了很多关于 DTO 及其有用性的信息，但我找不到在 ASP.NET 上下文中使用它的好例子。
假设我使用三层架构：
我应该在哪里将 EF Employee 对象转换为 EmployeeDTO POCO？
假设我在数据访问层进行转换，但在 WCF 服务中会发生什么？然后是否应该将其转换为另一个 DataMember 对象，并且当它到达 UI 层（MVC Web 应用程序）时是否应该第三次将其转换为模型？如果有人能帮我解决这个问题，我将不胜感激
【问题讨论】：
标签： c# asp.net asp.net-mvc entity-framework wcf
在类似的情况下，我曾经将 dto 放入 Core 中，这三个人都知道。所以你有
核 | ------------ | | | DAL BL PL每一层都可以使用Core.Dto.Employee 操作。每一层还在其 API 中对外公开Core.Dto.Employee。但在内部，每一层都可以转换/适应Core.Dto.Employee，例如您从数据库EF.Employee 中读取，然后将其转换为Core.Dto.Employee。变换包含在图层的边界中。
如果您有几个不同的模型来表示整个层中的相同事物，例如 PL 想要 PL.Employee 而 DAL 对 EF.Employee 进行操作，那么您最终会一团糟。
【讨论】：
您的服务层公开了 DTO。这意味着在服务层中，您可以根据希望将数据合约暴露给外界来定义数据合约。在大多数情况下，它们是扁平实体，不一定具有与您的数据库实体相同的结构。
您的服务层负责使用业务/数据层并构建您向外界公开的 DTO。
您在业务和数据层中使用的内容取决于架构。您可以拥有一个首先使用代码映射的域模型。在这种情况下，服务层将域实体映射到数据合同 (DTO)。如果您没有域模型（贫血模型），那么您也可以直接将数据库映射到您的 DTO。
ASP.NET MVC 站点使用该服务，并将其接收到的 DTO 映射到专用视图模型，然后将其传递给特定视图。
此外，您还可以决定将查询与命令分开。这是一个很好的方法，因为您作为查询请求返回的 DTO 与您发送到服务的命令完全不同。命令仅包含执行命令所需的内容并包含您想要实现的业务意图，而查询则返回您在 UI 中所需内容的扁平化模型。
其他说明：
【讨论】：
看看这里添加的https://stackoverflow.com/a/6310507/1771365，因为我没有足够的声誉来添加 cmets。
就我个人而言，我会在持久层和业务层之间传递实体。当您使用 MVC 时，您可能会将视图模型传递给您的控制器。此时我会将您的视图模型映射到您的 DTO。
如果您计划在所有层之间使用 DTO，则创建一个横切项目，然后您可以参考。
【讨论】：
我特别喜欢的一种方法是在您的业务层中进行 DTO 转换。
场景：您的表示层通过 DTO 调用您的业务层。您进行一些逻辑和验证，然后将 DTO 转换为实体并将其发送到您的数据访问层。
即UI --> 总线。层（转换为实体）--> 数据层
我喜欢这种方法，因为我认为数据层不应该有任何转换逻辑，并且应该根据需要接收和处理实体。这有效的另一个原因是您现在可以在转换过程中定义特定的业务规则/验证逻辑，然后再将其发送到数据层。 这是一个旧的MSDN article，但有一些很好的细节解释了类似的方法。
【讨论】：
UserDTO CreateUserDTO()，它返回一个新初始化的 DTO。另一种方式（我更喜欢）是在 UI 层中简单地实例化它：var dto = new UserDTO()。由于您的 DTO 可用于您的 UI，因此您可以简单地实例化 DTO，将其填充到 UI 中，然后将其发送到业务层以进行保存或其他任何操作。最后，当您从数据库中填充 DTO 时，您的业务层将简单地返回一个填充的 DTO 实例：UserDTO GetUserByID(int id)
我为此目的使用了一个名为 Shared 的项目，特别是与所有层共享对象。无论名称如何，它都应该对所有层可见。
【讨论】：
不应该有任何转换。您只需将 Poco 对象用作 DTO。
EF 与 Poco 一起工作，它们可以被 WCF 序列化。
它们应该在所有项目引用的程序集中定义。
在 ASP.NET MVC 中，您可以使用 Poco - DTO 映射到 ViewModel。
【讨论】：