Question

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

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

DataAccess将实体框架与代码优先方法结合使用，因此它包含数据库表的模型。

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

我已经了解到Service项目不应该使用DataAccess项目的模型，那么在Service或Business中应该在哪里创建这些模型？

谢谢。

Answer 1

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

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

为什么？

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

Answer 2

我不知道这是否是最佳实践，但是我开发了许多项目，这些项目在Windows服务，Web API等之间包含许多共享的逻辑和功能。它们都遵循类似的方式：

包装器-包含接口，模型和代码，以简化从另一个.NET项目中调用WebAPI的过程。 完全没有引用其他项目

核心-包含所有复杂的业务逻辑。服务层，数据访问层，帮助程序类等。参考包装器和其他所需的功能

WebAPI-仅包含在Core 用于模型/接口的参考包装和用于业务逻辑的Core中的服务层功能周围创建WebAPI所需的代码

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

这导致我看到一些人称之为“大型解决方案”或类似的东西，但是只要将代码保留在一个域中，就不会造成混乱。