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

Question

我想通过声明我是.NET框架和ASP.NET的新手来开始我的问题。但是，我正在尝试学习ASP.NET 5 MVC 6.我已阅读了许多教程，以帮助我加快速度。我从中学到的主要教程是“Learn MVC in 7 Days”

我认为我得到了所有的MVC架构，但有一些令我困惑的术语/层，即模型，业务逻辑层，数据访问层和视图模型。

以下是我对MVC架构的全面理解“如果错误，请纠正我”

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

但是，Model似乎还有另外3层，就像这样

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

另外，如果我想为我的控制器安装一个repository，这适合哪里？我明白这可能不是一个小应用程序所必需的，但我只是想了解并学习正确的方法然后我可以决定是否需要在我的应用程序中。

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

我将以一个例子来解释。

Answer 1

以下代码片段是从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的定义：

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

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