ASP.Net中的三层体系结构和MVC（模型，视图控制器）之间的区别

我很想知道3层架构与ASP.Net中的MVC（模型，视图控制器）有何不同，因为在我看来，该架构适用。

在3层中，我们有User Services Layer，BusinessLayer而DataAccessLayer在另一方面Model，中View，和Controller。在我看来，这是相同的体系结构。

谁能解释这两种架构的真正区别是什么，每一层之间又有什么不同？

这就像问一个苹果和一个苹果核之间有什么区别。这两种体系结构不能相互替代。我认为更准确的观点是3层体系结构增强了 MVC。

MVC架构

• 模型：这些代表应用程序中的“东西”。近年来，这一层变得有点模糊，我将在后面解释。

• 视图：用户界面。用户互动的事物。

• 控制器：响应用户和模型层更改的编程代码

三层架构

使用三层体系结构，您将具有不同职责的层。

• 用户服务：（或通常称为“服务”），这一层更多地是关于协调“模型”层的检索和修改。在这里执行复杂的多步骤操作

• 业务层：这表示蚀刻到编程代码中的业务规则。“业务”想要的是在此层中实施的。

• 数据访问层：一个或多个负责访问持久性数据存储的类。

与MVC相交的三层体系结构的唯一部分是“业务层”。MVC中的“模型”和三层体系结构中的“业务层”正试图实现相同的目标。

MVC中的“ M”变得模糊

近年来，MVC中的“模型”层有所扩展。从我所看到的，有两种，可能是三种模型：

1. 领域模型：这些模型代表“业务”关心的“事物”-业务领域。这些类保存数据以及对该数据进行操作的所有过程，以强制执行业务规则。通常，域模型与数据库中的表相关联。这似乎适合3层体系结构的“业务层”。

2. 视图模型：这些是用于将域模型中的数据整理为更适合视图的类。这不适用于3层体系结构中的任何地方，因为视图模型不实现业务逻辑，也不提供任何类型的服务或数据访问。

3. 业务模型：在复杂的应用程序中，需要将域模型与业务逻辑分离。业务模型包含数据和对该数据进行操作以实现业务规则的过程，而域模型则降级为“属性包”，即仅保存数据但不包含任何行为的对象。域模型成为数据库和应用程序之间数据传输对象的另一种形式。

在MVC中没有提到数据访问。在某些情况下，您会看到数据访问属于MVC的“模型”层，正如我们所看到的那样，它不再是明确的层。我确实看到3层架构与MVC 配对以创建整个应用程序。一个增加或改进另一个：

• 楷模
  • 域模型（MVC / 3层）
  • 查看模型（MVC）
  • （可选）业务模型（MVC / 3层）
• 观看次数（MVC）
• 控制器（MVC）
• 数据访问（3层）
• 服务（三层）

有一些交叉点，但是它们在很大程度上是分开的，并且一起用于解耦和隔离较大系统的各个组件。

不，他们不一样。

MVC是用于构造用户界面代码的设计模式。它可以用在三层体系结构中，在这种情况下，模式将属于用户服务层。但它也可以用于非三层应用程序中的UI-例如，没有基础持久性的计算器，因此没有数据访问层。

在具有MVC前端的三层体系结构中，用作模型的域对象将是业务层中的对象，但是MVC模式并未真正指定模型是哪种对象，仅指定了它们在模式中的作用是。例如，在MVVM变体中，模型是域对象顶部的UI特定适配器。在这种情况下，该模型也属于用户服务层。

我知道会有很多不同的答案，但是我会给你我的看法。

这是软件工程中最著名的答案，即“取决于”。

从本质上看，除了各种实现和理论上的差异外，这些都是非常相似的模式，流程相似。

它所依赖的是您正在构建的应用程序，一个简单的Webapp可能只有一个MVC层，通过ORM与数据库进行通信。更为复杂的可能是MVC处理用户层中的前端，而更复杂的非用户公开操作发生在BL层中，而数据层则由多个源组成。