在我的项目架构中从实体映射到 DTO 的层答案

【问题标题】：In which layer to map from entity to DTO in my projects architecture在我的项目架构中从实体映射到 DTO 的层
【发布时间】：2021-11-23 20:22:06
【问题描述】：

我知道有数千篇关于它的文章，我阅读了其中很多，但我仍然不确定我的具体情况该怎么做。

我正在编写一个 .NET Core 5 应用程序并且有 3 个项目层：

我在我的 DAL 层中使用实体，然后将它们映射到 DTO 模型，这些模型在 API 中返回给 API 调用者。

如果我在 Google 中写“在哪个层从实体映射到 DTO？” 我得到答案：

在这种情况下，服务层将域实体映射到数据合同 (DTO)。

问题是我没有服务层，我不想创建它。

问题是，我应该在我的层结构中的哪个层进行从实体到 DTO 的映射？

在我的结构中，我想我可以在 2 个地方做到这一点（我不确定哪个更好以及为什么）：

在 BLL 中 - 我可以将其映射到 DTO（使用 AutoMapper）并将 DTO 返回到 API 层，而不是返回实体。
在 API 中 - 从 BLL 接收实体，然后将其映射到 DTO（使用 AutoMapper 或 ResultFilter）并将其返回给 API 调用者。

【问题讨论】：

您不希望您的业务层依赖于数据层中的模型（实体）。所以，我想说你的存储库的主要目的是从数据层抽象出来，这样如果你决定以不同的方式构建你的数据库，你的业务逻辑就不会改变。
这是自以为是的，因此是题外话。但是，3 层架构已经过时了，转向更干净、更灵活的架构，比如洋葱架构
@Xerillio 我不太清楚你的意思，你的意思是在业务层做映射？

【解决方案1】：

造成这种混乱的原因是该架构在 BLL 层包含 2 个不同的职责。这些是应用程序逻辑和域逻辑。

如果您在架构中分离这些职责，则应将映射放在应用层。 see

1 - 在您的架构中，您不应该将映射保留在 DAL 中，因为 DAL 只是一个关于如何访问数据的层。

2 - 尽可能减少 API 层，因为这为表示技术提供了灵活性。因此，您可以轻松地将演示技术从 WebApi 更改为 MVC、Blazor、WPF、WinForm 等。

3 - 您可以在 BLL 中创建映射，但不要忘记映射和域逻辑是完全不同的职责。您的 BLL 会增长，而其凝聚力会降低。

我推荐清洁架构而不是这种架构。这个link中有一个示例项目

【讨论】：

【解决方案2】：

您的 BLL 似乎是服务层，如果不是，您最终应该拥有一个。

服务/业务逻辑层负责将数据库对象映射到 API 使用者理解的内容。

我会和 BLL 层一样，它绝对不属于处理程序级别（API 级别）也不属于数据存储库级别。

【讨论】：

【解决方案3】：

根据您的情况，我个人认为。我建议选择二。 Here 是一个类似问题的来源充分的答案，该问题扩展了原因。

本质上，由于对 DTO 的需求来自您的应用程序层（或者您称之为 API 层），因此它应该映射到 API 层中。

【讨论】：