如何将 DTO 文件映射到 .Net Core 项目中的模型

Question

我以前从未使用过 .Net Core 项目，但有使用 .Net 的历史，包括 MVC 和实体框架。我正在开发一个新的 .Net Core 项目，该项目有五个解决方案文件夹：EHA.PROJ.API、EHA.PROJ.DTO、EHA.PROJ.Repository、EHA.PROJ.Repository.Test 和 EHA.PROJ.Web。EHA.PROJ.DTO 文件夹有许多文件，例如 CategoryDTO.cs，如下所示

namespace EHA.PROJ.DTO
{
    public class CategoryDescDTO
    {
        public int CategoryRef { get; set; }

        public string CategoryName { get; set; }
    }
}

我希望设置一个映射安排，以将数据从 EHA.PROJ.DTO 文件获取到 EHA.PROJ.Web 文件夹中模型文件夹中的模型文件。我一直在浏览，因为我以前从未做过类似的事情，因为我之前使用实体框架和通过连接字符串完成的连接来处理 DAL 文件夹中的数据。我猜测必须有一些过程来映射 dbContext 中的数据以连接两个文件夹中的文件。我确实找到了一些关于 AutoMapper 的信息，但不确定如何实现它。

.Net Core 的这种安排对我来说是新的，因此如果有人可以帮助提供任何示例或为我指出正确的方向，我将不胜感激。

Answer 1

您的第一个问题是将您的实体放入您的网络项目中。马上，您的 Web 项目和数据层之间就形成了紧密耦合，这几乎否定了所有其他层的意义：DTO、存储库等。您希望将实体和上下文移出到真正的实体和上下文中。数据层（即与您的 Web 项目分开的类库项目）。

然后，您需要决定数据层应扩展多远。如果 API 是为网站提供数据，那么您实际上希望从 Web 项目中删除对数据层的所有依赖项。您的 DTO 项目将在 API 和 Web 项目之间共享，并且您的 API 将发送/接收您的 DTO，在后台实体之间来回映射。

但是，如果您打算这样做，那么存储库项目应该完全消失。只需让您的 API 直接与 EF 和您的实体一起工作即可。你的抽象是 API 本身；不需要另一个。拥有存储库层的唯一原因是 API 和 Web 都直接使用存储库，这实际上不是一个很好的模式。您将不可避免地得到一堆特定于每个项目的重复逻辑。

简而言之，当使用像 EF 这样的 ORM 时，存储库模式是多余的。ORM是您的数据层。您只是使用第三方提供的 DAL，而不是您自己创建的 DAL。仅当直接使用 ADO.NET 等工具直接使用 SQL 时，存储库模式才有意义。否则，摆脱它。

如果您的目标只是隐藏数据层，那么拥有 API 就足够抽象了。该网站对底层数据源一无所知，API 实际上只是一个通过 HTTP 返回 JSON 的服务层，而不是直接返回对象实例，即 API本质上是您的“存储库”层。

通过转向基于微服务的架构，这种情况可以得到进一步改善。这样，您基本上就拥有了多个小型、独立的 API，它们仅适用于您的域或功能的一部分。每个都可以直接使用 EF，或者完全不同的 ORM，甚至完全不同的堆栈。您可以在 Node.js 或 python 等上构建 API。网站只是向各种服务发出请求以获取所需的数据，并不知道或关心这些服务实际如何工作。