分层设计/架构答案

【问题标题】：Layered Design /Architecture分层设计/架构
【发布时间】：2018-09-26 12:43:35
【问题描述】：

我们在与 DAL 通信以进行数据访问操作的服务中使用带有 Webapi 的 html 5/angular SPA

层流是：

presentation(html5/angular controllers/service) --> web api --> DAL - -> DB。

我们没有这样的 BLL 项目。我们正在考虑将 DAL 作为 BLL + DAL 的组合。我们使用通过 t4 模板创建的 DTO 对象，它们用于客户端和 Web api 和 DAL 之间的数据传输（我们不使用 EF，我们使用 ADO.Net 作为底层提供者）

我们应该需要一个单独的 BLL 项目还是可以将 BLL 和 DAL 项目结合起来？考虑到它应该是可测试和可扩展的。
如前所述，始终使用 DTO 对象。我们是否需要除 DTO 之外的任何模型来在客户端和 webapi/DAL 之间传输数据？

达尔：

public List GetCustomers {} 这使用数据访问帮助程序类来获取客户并转换为 DTO

上面的 CustomerDAL.GetCustomers 正在被 webapi 项目调用。此时，（比如客户）的任何 BL 都是在 web Api 项目中编写的，有时是在 DAL 项目中编写的。为了一致性和可测试性，我们正在考虑将它们转移到一个项目中。

对此的任何见解都会有所帮助。

【问题讨论】：

标签： asp.net-web-api architecture single-page-application data-access-layer business-logic-layer

【解决方案1】：

拥有独立 BLL 的最大价值在于，我的应用程序（业务逻辑）中最重要/最昂贵的部分位于不依赖于数据库或 web/http 框架的区域。这意味着当下一件大事（数据库、平台等）出现时，我可以重用我的业务层。

更重要的是，DAL 和 UI 层的测试成本要高得多。当我在 UI 或 DAL 层编写单元测试时，我最终会为每个函数测试 1-2 个场景……当我在 BAL 层进行测试时，我会创建更多的场景，因为它是如此便宜（努力）。这让我可以以更低的成本获得更好的覆盖范围。

也许您的应用程序没有太多业务逻辑。如果它们纯粹是围绕数据库表的 CRUD 包装器，则可能无法证明费用是合理的。大多数应用程序包含的业务逻辑比开发人员愿意承认的要多得多。查看您在 WebAPI 中运行的验证...这些可能都是业务规则。查看您的安全限制，这些也可能是业务规则。

是否使用 DTO 或更复杂的域模型取决于您的设计、环境和团队限制，我不会在 15 分钟的帖子中轻松解决这些问题。 Fowler 有一些强烈的意见，称之为Anemic Domain Model antipattern，但我已经看到它非常成功地用于大型项目。此模型的优点之一是您不需要对应用程序模型进行如此多的连贯图，这通常是大型分散团队的情况。

【讨论】：