model-view-controller - MVC 模式是描述角色还是层？

Question

我最近读到一篇文章，说 MVC 模式描述了应用程序中的层。但就我个人而言，我看到 MVC 在应用程序中显示了几个关键角色。

您认为哪个词更适合描述 MVC 的三个主要部分，层或角色？

Answer 1

层应该意味着各个代码集之间的耦合非常窄。MVC 涉及模型、视图和控制器之间相对紧密的耦合。因此，如果您将其描述为分层模式，则在定义层之间的 API 方面会出现问题。要正确执行此操作，您必须实现一些不直观的模式。

因此，我同意您将其视为在单个层中定义角色的模式的倾向。

Answer 2

我认为角色是一个更好的描述。视图和控制器都在同一个“层”中，通常模型被描述为一个层，但在层之间使用。

通常，我的应用程序以域模型为中心，并围绕它进行演示、持久性和文件 io 等内容。将架构视为分层的想法并不适合我。

Answer 3

MVC 清楚地定义了 ROLES。这些是您可以在任意数量的层中实现的 3 个角色。例如你可以有一个多层控制器

Answer 4

角色，而不是层。层完全依赖于 MVC 模式的底层实现。例如，服务层在一个实现上可能是单层，但在另一个实现上它可能有一个 Web 服务远程处理层和一个数据库层（用于两个不同的服务层）。层的概念只是为了帮助您组织它，就像模式一样，但是层不像模式那样容易被发现，而且层可以改变，而尽管层因不同的实现而发生变化，但模式保持不变。

Answer 5

您无法比较这两个词，因为它们描述了不同的概念。对我来说，层是不透明的，它提供了一些我可以用来做事的功能。例如，一个好的无线发射器硬件层只会给我一个发送和一个接收功能（例如，基于字节），对我隐藏所有丑陋、丑陋的细节。
角色是对象的行为方式。例如，我的一个编译器中的转换将采用抽象语法树并返回抽象语法树，或者我当前项目中的情感将采用状态差异并返回特定更改的状态差异。

但是，有了这两个定义，我认为没有必要选择一个“正确”的术语而将另一个视为错误的，因为它们并没有太大的冲突。一个层的一部分具有一定的作用，一组符合一定作用的对象构成一个层。当然，控制器在 UI 和模型之间形成了一个特定的层（至少对于输入），但是，它也有一个作用——它将某个事件转换为某些其他事件（因此，它是某种适配器）。

Answer 6

我认为两者都可以合理地论证，但我认为将这些部分描述为“层”更符合其他约定，例如OSI 模型。由于视图、控制器和模型越来越接近您的数据，它更像是一个分层结构。似乎“角色”将适用于同一层上应用程序的不同部分。

Answer 7

这都是术语，但我认为正确的软件架构术语应该是“层”，就像在逻辑层中一样。如果更清楚，您可以使用术语“架构层”。

问题是，这只是对应用程序进行切片的另一种方式：经典的 n 层应用程序是：

• 用户界面
• 商业逻辑
• 持久性

您可以在一个简单的 MVC 应用程序中拥有以下逻辑层：

• 用户界面
• 控制器
• 模型
• 持久性

但是您仍然可以将“UI”和“控制器”一起讨论为构成用户界面层——不过，在描述和绘制这些架构时，我通常将控制器拆分为一个单独的层。

Answer 8

为什么不兼得？我将其视为实现 3 个不同角色的 3 个独立层。