MVC 架构中的模型/业务层/数据访问和存储库有什么区别？

Question

我喜欢先说我完全是 .NET 框架和 ASP.NET 的新手来开始我的问题。但是，我正在尝试学习 ASP.NET 5 MVC 6。我已经阅读了很多教程来加快速度。我从中学到很多的主要教程是“Learn MVC in 7 Days”

我认为我总体上了解了 MVC 架构，但有一些术语/层让我感到困惑，即模型、业务逻辑层、数据访问层和视图模型。

以下是我对MVC架构的整体理解“如有错误请指正”

• (M) 模型：是表示数据库表的对象。数据库中的每个表都是一个模型。每个表中的每一列都是模型对象中的一个属性。例如，如果我有一个名为“users”的表，其中包含以下列id、firstname、lastname 和username，那么模型将被称为user 和“id,firstname”， lastname 和 username" 是属性。
• (V) 视图：通过将数据放入 HTML 页面中，将数据呈现给最终用户的方式。
• (C) 控制器：是由路由引擎调用的层。控制器类包含一些关于用户应该看到哪些数据/视图的逻辑。例如，UsersController 类有一个名为 Index() 的方法，它从 user 模型请求一些数据，然后返回一个名为 ShowAllUsers 的视图。

不过，Model 下方似乎还有另外 3 层

• 查看模型：这似乎是将来自模型的原始数据转换为可呈现的“视图就绪”格式的一种方式。例如，如果我们想向最终用户显示用户的全名，但我们没有全名作为模型中的属性。然后我们这一层将创建一个新对象，该对象与模型对象相同，并具有一个称为全名的附加虚拟属性。因此，我们现在可以在视图中显示 obj.fullname。
• 业务逻辑层
• 数据访问层

此外，如果我想为我的控制器设置一个repository，这适合这里吗？我明白这对于小型应用程序可能不是必需的，但我只是想了解和学习正确的方法，然后我可以决定我的应用程序是否需要它。

我的问题是什么是业务逻辑层，什么是数据访问层？ repository 适合放在哪里？

我会很感激一个例子的解释。

Answer 1

MVC 只是关于表示层。不要仅仅因为它包含单词 Model 就将它与业务和数据层的解决方案混淆

首先让我们谈谈分层架构的工作原理：

这个想法很简单。顶层依赖于下层。所以，表示层依赖于业务层，业务层依赖于数据层。也就是说，Business层定义业务逻辑，为Presentation层提供接口，Data层定义数据访问逻辑，为Business层提供接口

现在让我们谈谈 MVC 是什么：

• V(View) - 存在 UI 逻辑。
• M(Model) - 是业务逻辑层的接口。理解很重要 这不是业务逻辑本身，它只是接口。这就是为什么 我们说表示层依赖于业务层 - 因为它使用它的接口
• C(Controller) - 这是你调用业务层接口和 将接收到的数据映射到 View。

还要检查以下答案：

• How should a model be structured in MVC?
• Architecture more suitable for web apps than MVC?

Answer 2

以下 sn-ps 摘自 MSDN 上的一些教程，您可能会觉得有帮助：

Data Access Layer

处理数据时，一种选择是将特定于数据的逻辑直接嵌入表示层（在 Web 应用程序中，ASP.NET 页面构成表示层）。这可能采取在 ASP.NET 页面的代码部分中编写 ADO.NET 代码或使用标记部分中的 SqlDataSource 控件的形式。无论哪种情况，这种方法都将数据访问逻辑与表示层紧密耦合。然而，推荐的方法是将数据访问逻辑与表示层分开。这个单独的层被称为数据访问层

Business Logic Layer

第一个教程中创建的数据访问层 (DAL) 将数据访问逻辑与表示逻辑清晰地分开。然而，虽然 DAL 将数据访问细节与表示层清晰地分开，但它并不强制执行任何可能适用的业务规则。例如，对于我们的应用程序，当 Discontinued 字段设置为 1 时，我们可能希望禁止修改 Products 表的 CategoryID 或 SupplierID 字段，或者我们可能希望强制执行资历规则，禁止员工由以下人员管理的情况在他们之后受雇的人。另一个常见的场景是授权——也许只有特定角色的用户才能删除产品或更改 UnitPrice 值。 在本教程中，我们将了解如何将这些业务规则集中到一个业务逻辑层 (BLL) 中，该层充当表示层和 DAL 之间数据交换的中介。

通过Code Project article，我发现以下对数据访问层用途的描述非常有用：

数据访问层为对数据库的所有调用提供了一个集中位置，因此可以更轻松地将应用程序移植到其他数据库系统。

我还找到了this blog post，它很好地说明了业务逻辑层如何与存储库集成：

最后，这里是微软对business logic的定义：

业务逻辑被定义为与应用程序数据的检索、处理、转换和管理有关的任何应用程序逻辑；业务规则和政策的应用；并确保数据的一致性和有效性。为了最大限度地提高重用机会，业务逻辑组件不应包含任何特定于用例或用户故事的行为或应用程序逻辑。

我希望我能提供我自己对这些层的专家描述，但我也在学习这个主题，所以我想我会分享我发现的东西，希望我们都能从中学到一些东西。与这些层相关的示例问题，请参考我上面链接的教程。