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

首先，我想说明我对.NET framework和ASP.NET都是新手。然而，我正在努力学习ASP.NET5 MVC6。我读了很多教程来提高我的学习速度。我从中学到很多的主要教程是“”

我想我总体上了解了

MVC

体系结构，但有一些术语/层让我感到困惑，即模型、业务逻辑层、数据访问层和视图模型

以下是我对MVC架构的总体理解“如果有错，请纠正我”

• （M） 模型：是表示数据库表的对象。数据库中的每个表都是一个模型。每个表中的每个列都是模型对象中的一个属性。例如，如果我有一个名为“users”的表，其中包含以下列

  id

  ，

  firstname

  ，

  lastname

  和

  username

  ，那么模型将被称为

  user

  ，

  id

  ，

  firstname

  ，

  lastname

  和

  username

• （五） 视图：通过将数据放入HTML页面向最终用户显示数据的方式
• （C） 控制器：路由引擎将调用的层。控制器类包含一些关于用户应该看到哪些数据/视图的逻辑。例如，

  UsersController

  类有一个名为

  Index（）

  的方法，该方法从

  user

  模型请求一些数据，然后返回一个名为

  showallers

  的视图

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

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

另外，如果我想为我的控制器安装一个控制器，那么这个在哪里合适呢？我知道这对于一个小的应用程序来说是不必要的，但我只是试图理解和学习正确的方法，然后我可以决定在我的应用程序中是否需要它

我这里的问题是什么是业务逻辑层，什么是数据访问层？那么这件衣服在哪里合适呢

---

请给我举个例子进行解释。

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

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

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

从a中，我发现对数据访问层用途的描述特别有用：

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

我还找到了一个在说明业务逻辑层如何与存储库集成方面做得很好的例子：

最后，以下是Microsoft对以下内容的定义：

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

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

MVC只是关于表示层的。不要因为它包含单词Model而将其与业务层和数据层的解决方案混淆 首先让我们谈谈分层体系结构是如何工作的：

这个想法很简单。顶层依赖于下层。所以，表示层依赖于业务层，业务层依赖于数据层。换句话说，业务层定义业务逻辑并为表示层提供接口，数据层定义数据