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

Question

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

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

这里是我对MVC架构的整体理解“如有不妥请指正”

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

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

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

此外，如果我想要一个 repository对于我的 Controller ，这里适合放在哪里？我知道这对于小型应用程序可能不是必需的，但我只是想了解和学习正确的方法，然后我可以决定我的应用程序是否需要它。

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

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

Answer 1

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

Data Access Layer

When working with data one option is to embed the data-specific logic directly into the presentation layer (in a web application, the ASP.NET pages make up the presentation layer). This may take the form of writing ADO.NET code in the ASP.NET page's code portion or using the SqlDataSource control from the markup portion. In either case, this approach tightly couples the data access logic with the presentation layer. The recommended approach, however, is to separate the data access logic from the presentation layer. This separate layer is referred to as the Data Access Layer

Business Logic Layer

The Data Access Layer (DAL) created in the first tutorial cleanly separates the data access logic from the presentation logic. However, while the DAL cleanly separates the data access details from the presentation layer, it does not enforce any business rules that may apply. For example, for our application we may want to disallow the CategoryID or SupplierID fields of the Products table to be modified when the Discontinued field is set to 1, or we might want to enforce seniority rules, prohibiting situations in which an employee is managed by someone who was hired after them. Another common scenario is authorization – perhaps only users in a particular role can delete products or can change the UnitPrice value. In this tutorial we'll see how to centralize these business rules into a Business Logic Layer (BLL) that serves as an intermediary for data exchange between the presentation layer and the DAL.

来自Code Project article , 我发现对数据访问层目的的描述特别有用:

The data access layer provides a centralized location for all calls into the database, and thus makes it easier to port the application to other database systems.

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

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

Business logic is defined as any application logic that is concerned with the retrieval, processing, transformation, and management of application data; application of business rules and policies; and ensuring data consistency and validity. To maximize reuse opportunities, business logic components should not contain any behavior or application logic that is specific to a use case or user story.

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