我最近读了一段文字，说MVC模式描述了应用程序中的层。但是我个人认为MVC在应用程序中显示了几个关键角色。

我们认为用哪个词更好地描述MVC的三个主要方面？

解决方案

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

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

但是，有了这两个定义，我认为没有必要选择一个"正确的"术语并把另一个术语错误地烧掉，因为它们之间的冲突并不多。层的一部分具有特定角色，并且符合某些角色的一组对象形成一个层。当然，控制器在UI和模型之间形成了一定的层(至少用于输入)，但是，它还具有将特定事件转变为其他事件的作用(因此，它是某种适配器)。

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

通常，我的应用程序以领域模型为中心，周围围绕着表示，持久性和文件io等内容。考虑分层的体系结构对我来说真的行不通。

我认为可以合理地争论两者之一，但是我认为将零件描述为"层"与其他约定(例如OSI模型)更加一致。由于视图，控制器和模型逐渐接近数据，因此它更多是分层结构。看来"角色"将应用于同一层上应用程序的不同部分。

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

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

所有这些都是术语，但是我认为正确的软件体系结构术语应该是"层"，就像逻辑层一样。如果更清晰，则可以使用术语"建筑层"。

事实是，这只是切片应用程序的另一种方式：经典的n层应用程序是：

• 使用者介面
• 商业逻辑
• 坚持不懈

在一个简单的MVC应用程序中，我们可能具有以下逻辑层：

• 使用者介面
• 控制器
• 模型
• 坚持不懈

但是在形成用户界面层时，我们仍然可以一起讨论" UI"和" Controller"-尽管在描述和图解这些体系结构时，我通常将Controller分成一个单独的层。

MVC明确定义了ROLES。这是我们可以在任意数量的层中实现的3个角色。例如你可以有一个多层控制器

角色，而不是层次。层完全取决于MVC模式的基础实现。例如，一个服务层在一个实现上可以是一个单层，但在另一个实现上可以具有一个Web服务远程处理层和一个数据库层(用于两个不同的服务层)。层的概念只是为了像模式一样组织起来，但是层并不像模式那样容易被发现，并且层可以更改，尽管层由于不同的实现而有所变化，但模式仍然相同。