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

Question

我喜欢通过声明我是 .NET 框架和 ASP.NET 的新手来开始我的问题。但是，我正在尝试学习 ASP.NET 5 MVC 6。我已经阅读了很多教程来加快速度。我从中学到了很多东西的主要教程是“在 7 天内学习 MVC ”

我想我已经了解MVC了所有架构，但是有一些术语/层让我感到困惑，即模型、业务逻辑层、数据访问层和视图模型。

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

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

然而，模型似乎在它下面还有另外 3 层，就像这样

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

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

我的问题是什么是业务逻辑层，什么是数据访问层？并且将在什么地方库适合在这里？

我会欣赏一个例子的解释。

Answer 1

以下片段摘自 MSDN 上的一些教程，您可能会发现它们很有帮助：

\n\n

数据访问层

\n\n

\n

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

\n

\n\n

业务逻辑层

\n\n

\n

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

\n

\n\n

从代码项目文章中，我发现对数据访问层用途的描述特别丰富：

\n\n

\n

数据访问层为所有数据库调用提供了一个集中位置，从而更容易将应用程序移植到其他数据库系统。

\n

\n\n

我还找到了这篇博客文章，它很好地说明了业务逻辑层如何与存储库集成：

\n\n

\n\n

最后，这是微软对业务逻辑的定义：

\n\n

\n

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

\n

\n\n

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

\n