在我的项目架构中从实体映射到 DTO 的层
In which layer to map from entity to DTO in my projects architecture
我知道有成千上万篇关于它的文章，我读了很多，但我仍然不确定我的具体情况该怎么做。
我正在编写一个 .NET Core 5 应用程序并且有 3 个项目层：
- API - REST，与客户端代码交互，获取 & returns DTO。
- BLL - 业务逻辑 - 大部分代码都在这里。
- DAL - 存储库模式 => 调用 SQL 服务器数据库。与实体一起工作。
我在我的 DAL 层中使用实体，稍后将它们映射到 DTO 模型，这些模型在 API 中 returned 到 API 调用者。
如果我写 Google “在哪一层从实体映射到 DTO？” 我得到答案：
In that case, the service layer maps domain entities to data contracts (DTO's).
问题是我没有服务层，不想创建。
问题是，我应该在层结构中的哪一层进行从实体到 DTO 的映射？
在我的结构中，我想我可以在两个地方做（我不确定哪个更好，为什么）：
在 BLL 中 - 而不是 returning 实体，我可以将它映射到 DTO（使用 AutoMapper）和 return DTO 到API层。
在API中——从BLL接收实体然后将其映射到DTO（使用AutoMapper或ResultFilter）和return将它发送给 API 来电者。
您的 BLL 似乎是服务层，如果不是，您最终应该有一个。
将数据库对象映射到 API 消费者理解的东西的责任是 service/business 逻辑层 .
我会像对待任何东西一样使用 BLL 层，它绝对不属于处理程序级别（API 级别）也不属于数据存储库级别。
根据你的情况，我个人的看法。我会建议选项二。 Here 是一个类似问题的来源很好的答案，它扩展了原因。
本质上，由于对 DTO 的需求来自您的应用程序层（或您称之为 API 层），因此应将其映射到 API 层。
造成这种混乱的原因是该架构在 BLL 层中包含 2 个不同的职责。这些是应用程序逻辑和领域逻辑。
如果您在架构中分离这些职责，则应将映射放在应用层。 see
1 - 在您的体系结构中，您不应将映射保留在 DAL 中，因为 DAL 只是关于如何访问数据的一层。
2 - 使 API 层尽可能少，因为这提供了表示技术的灵活性。因此，您可以轻松地将表示技术从 WebApi 更改为 MVC、Blazor、WPF、WinForm 等。
3 - 您可以在 BLL 中创建映射，但您不应忘记映射和域逻辑是完全不同的职责。你的 BLL 会增长，它的 cohesion 会降低。
我推荐 Clean Architecture 而不是这个架构。 link
中有一个示例项目
我知道有成千上万篇关于它的文章，我读了很多，但我仍然不确定我的具体情况该怎么做。
我正在编写一个 .NET Core 5 应用程序并且有 3 个项目层：
- API - REST，与客户端代码交互，获取 & returns DTO。
- BLL - 业务逻辑 - 大部分代码都在这里。
- DAL - 存储库模式 => 调用 SQL 服务器数据库。与实体一起工作。
我在我的 DAL 层中使用实体，稍后将它们映射到 DTO 模型，这些模型在 API 中 returned 到 API 调用者。
如果我写 Google “在哪一层从实体映射到 DTO？” 我得到答案：
In that case, the service layer maps domain entities to data contracts (DTO's).
问题是我没有服务层，不想创建。
问题是，我应该在层结构中的哪一层进行从实体到 DTO 的映射？
在我的结构中，我想我可以在两个地方做（我不确定哪个更好，为什么）：
在 BLL 中 - 而不是 returning 实体，我可以将它映射到 DTO（使用
AutoMapper）和 return DTO 到API层。在API中——从BLL接收实体然后将其映射到DTO（使用
AutoMapper或ResultFilter）和return将它发送给 API 来电者。
您的 BLL 似乎是服务层，如果不是，您最终应该有一个。
将数据库对象映射到 API 消费者理解的东西的责任是 service/business 逻辑层 .
我会像对待任何东西一样使用 BLL 层，它绝对不属于处理程序级别（API 级别）也不属于数据存储库级别。
根据你的情况，我个人的看法。我会建议选项二。 Here 是一个类似问题的来源很好的答案，它扩展了原因。
本质上，由于对 DTO 的需求来自您的应用程序层（或您称之为 API 层），因此应将其映射到 API 层。
造成这种混乱的原因是该架构在 BLL 层中包含 2 个不同的职责。这些是应用程序逻辑和领域逻辑。
如果您在架构中分离这些职责，则应将映射放在应用层。 see
1 - 在您的体系结构中，您不应将映射保留在 DAL 中，因为 DAL 只是关于如何访问数据的一层。
2 - 使 API 层尽可能少，因为这提供了表示技术的灵活性。因此，您可以轻松地将表示技术从 WebApi 更改为 MVC、Blazor、WPF、WinForm 等。
3 - 您可以在 BLL 中创建映射，但您不应忘记映射和域逻辑是完全不同的职责。你的 BLL 会增长，它的 cohesion 会降低。
我推荐 Clean Architecture 而不是这个架构。 link
中有一个示例项目