DTO、数据层和返回类型[关闭]答案

【问题标题】：DTO, Data Layer and types to return [closed]DTO、数据层和返回类型[关闭]
【发布时间】：2018-12-03 08:04:32
【问题描述】：

在我的工作中，我们使用实体框架进行数据访问。我正在创建一个数据访问层、一个业务访问层和几个不同类型的项目来访问 BLL（客户端应用程序与之交互的 webAPI、多个 MVC 网站和几个不同的桌面 WinForm 应用程序）。

我将 DTO 添加到名为“DTO”的单独项目中。此解决方案中此项目的目标是拥有一个 DLL，其中包含将来回传递的类和接口的所有定义。这样，这个项目可以在其他解决方案中创建为 git 子模块，并更新以供所有 UI 项目共同使用。我不会处理所有的 UI，因为我们将更多的开发人员带入项目中，我们可能需要有多个 VS 解决方案。

我的想法是让数据访问层返回并接收 DTO 而不是实体对象。这将完全解耦过程。

如果我们想用其他东西替换 DAL，只要它遵循 DTO 项目中定义的接口，我们应该没问题。我还认为这会使测试更容易，因为我可以用一个项目替换 DAL，以使用 Seed.net 之类的东西生成 DTO。考虑到我们的环境，顺便说一句，替换是真正的可能性。

增加这一层复杂性是不好的还是违反设计标准的？有什么我遗漏的吗？

【问题讨论】：

虽然这是一个固执己见的问题，但您所描述的是恕我直言，在这种情况下相当普遍。 DAL 接收和返回 DTO 而不是实体是很常见的，考虑到好处，我不会将其视为增加的复杂性
不，它不违反标准，而是完全相反：它是标准，它被称为分层设计架构。我不确定您所说的 DTO 接口 是什么意思。如果你的意思是 c# interface 那么让 DTO 实现一个接口是很奇怪的。如果你的意思是公共接口，那很好。

标签： c# design-patterns data-access-layer dto

【解决方案1】：

这就是我的工作方式，在云世界工作了几年，这似乎是每个人的工作方式。通常你有以下项目（每个构建到一个单独的程序集）

- REST controllers
- Models 
    that are used to pass information between Controller layer and Business Logic
- Business Logic Interfaces  (like ImyService)
- Business Logic  (like myService)
- DTOs
- IRepository (like ImyRepo)
- Repository (like myRepo)
     --> this is the same as DAL.

这样做的好处是，如果您添加依赖反转 (IoC)，那么您可以制作一个模拟 Repo，以便通过将其注入 NUnit 单元测试来隔离和测试服务（业务逻辑）层等.

业内人士（包括我）经常使用 AutoMapper 将模型转换为 DTO 到实体，反之亦然。

【讨论】：