ASP.NET MVC 模型和业务对象

Question

我正在寻找有关如何将业务规则合并到 asp.net mvc 应用程序以及它们如何与模型相关的一些指导。

首先有一点背景知识，这样我们就知道什么样的解决方案对于这个问题是相对的。在工作中，我们使用 WinForms、MVP、BusinessObjects、DataAccessObjects 和 DataTransferObjects。层的边界使用 DTO 将参数发送到方法并作为返回类型，或返回 List 类型。

现在我们正在添加一个外观层来将 DTO 转换为域对象以供 UI 使用，因为架构师不喜欢在 PresentationLayer 中使用 DTO 目前的工作方式。除了实用与否之外，我对所有这些理论上都很满意。

我制作一个网站是为了好玩，但出于考虑，可以说它提供的流量与 SO 相同，我上次听说的一个月点击量约为 60,000 次。我对控制器和视图的机制以及模型如何与两者集成感到满意。

我使用 NerdDinner 作为构建站点的示例，并遵循示例中的存储库模式实现。我不明白如何将业务对象合并到组合中。

我听说人们将 LINQ 称为 DataAccessLayer/DataAccessObjects。如果我像我习惯的那样通过业务对象强制我的所有请求，我已经引入了一些奇怪的依赖项。我的 UI 和我的 BO 都必须了解我的 DAO。

有意义的是将 LINQ 类用作真正的 DAO 层，将其隐藏在 BO 后面，并在 POCO 和 LINQ 对象之间进行 BO 转换。

我唯一担心的是我可以很好地将我的 UI 绑定到 LINQ 类，并且真的不需要所有额外的工作，我对 NerdDinner 中的轻量级方法感到满意。

所以我本质上是在控制器中实例化的存储库，它接收和返回 LINQ 对象。我的业务对象有静态方法，它们只接受 LINQ 类并执行一些计算，比如应用某个州的税 % 或 w/e。

由于必须在存储库的结果中完成大量计算，我正在考虑将它们组合到一个中心区域，例如外观层，但它只是对数据进行转换而不转换为其他对象集（DomainObjects DTO）。

我应该这样做，还是应该说这些业务方法确实是我的模型的一部分，并且它们应该在返回对象的存储库方法中？

Answer 1

从设计的角度来看，我会这样设计。当然命名只是为了这篇文章的目的，你不必命名你的 DAL 和 BLL ..Repository 和 ..Service。

拥有应该进行数据访问/查询的存储库（或一个）。理想情况下，它应该只包含查询（编译或未编译）。我个人对每种数据类型都有一个存储库，以帮助保持查询分开。

下一层应该是你的业务层，我喜欢称之为服务。这些类负责所有关于验证、准备步骤和任何其他需要完成的逻辑，以使服务的消费者获得所需的信息。与 ASP.NET MVC 应用程序一样，我的服务返回视图模型，然后将其直接传递到强类型视图中。对于我的服务，我通常将它们按逻辑分组在一起，而不是为每种数据类型分组。

这是一个很棒的设计，因为它使您的数据访问代码和表示代码保持简洁，并且大多数可能出错的逻辑都在您的服务（或业务）层中。