3 层 - 模型重用？

Question

我正在创建一个包含这三个不同项目的应用程序：

ApiService (Web API 2)
BusinessLogic (Class Library)
DataAccess (Class Library)

• ApiService 引用了 BusinessLogic
• BusinessLogic 引用了 DataAccess

DataAccess 使用 Entity Framework 和代码优先方法，因此它包含数据库表的模型。

我的问题是，关于商业和服务项目模型的最佳方法或最佳实践是什么？

我读到服务项目不应使用 DataAccess 项目的模型，那么我应该在哪里创建该模型，是在服务中还是在业务中？

提前致谢。

Answer 1

我不知道这是否是最佳实践，但我已经做了很多项目，其中包含 windows 服务、Web API 等之间的大量共享逻辑和功能。它们都遵循类似的东西为此：

Wrapper - 包含接口、模型和代码，使从另一个 .NET 项目调用 WebAPI 变得更容易。 完全没有引用其他项目

核心 - 包含所有丰富的业务逻辑。服务层、数据访问层、助手 类 等 引用包装器和任何其他需要运行的东西

WebAPI - 仅包含在核心 References Wrapper models/interfaces 和核心业务逻辑 [=10= 中围绕服务层功能创建 WebAPI 所需的代码]

其他使用 Core 的项目与 WebAPI 项目类似。例如，用于计划任务的控制台应用程序、用于持续数据处理的 Windows 服务等。

这会导致我看到一些人称之为 "mega solution" 或类似的结果，但只要您将代码保留在一个域中，就不会造成混乱。

Answer 2

始终将 BL(Business logic)/Presentation layer 个模型与 DAL(Data access layer) 个模型分开。

在它们之间再添加一层来进行映射，使用 Automapper 或自定义的东西。因此，当您将数据传递给 DAL 时，模型将映射到实体模型，而当 BL 从 DAL 获取数据时，将实体模型映射到 BL 模型,

为什么？

将数据保存在数据库中的方式可能与将数据呈现给用户的方式大不相同。数据可能必须从多个实体中获取，通过关系连接，通过从其他表连接在 运行 时间再次构建，等等。您将如何向用户展示它可能会被简化并且与它不同持久化，因此您可以隐藏数据库所需的复杂性。