我对 MVC 和多层 Web 架构的概念很陌生。我开发了一个 PHP 应用程序，并且正在使用一个可用的 MVC 框架。我的问题如下：
据我了解，MVC 本身并不被视为多层架构。我可以理解单独使用 MVC 如何比采用非结构化方法更上一层楼，但我正在考虑如何适应简单的 3 层架构？MVC 会驻留在表示层吗？添加分层方法的优点是什么？据我所知，仅使用 MVC 就没有明确的数据对象负责从数据库中检索数据，这通常被填充到模型中。同样，在 3 层架构中的业务逻辑将驻留在“业务层”（或任何您想调用的名称）中，可以填充到控制器中。
我的理解有些正确吗？我知道我问了很多问题，但我想听听您讨论如何将 n 层架构整合到您的 MVC 框架（PHP 或其他）中，因为我认为这两者并不相互排斥。谢谢！
M) M 是你的模型。这通常位于您的业务层或表示层后面的层。许多人不喜欢表示层对业务层有任何了解，因此他们通过拥有所谓的 ViewModel 进一步抽象了这一点。这些通常是松散地映射到您的域模型的 DTO（数据传输对象）。对我（.net 人）来说，有 AutoMapper 等工具可以将域模型转换为视图模型。
V) V 是你的观点。视图是您的表示层。这是用户直接接触并与之交互的实际 HTML 或 PHP 代码。视图应尽可能轻（意味着尽可能没有逻辑）。尝试将任何类型的 if/then 类型场景排除在视图之外，并坚持仅显示和收集数据。向您的网页设计师展示一个 ViewModel，这样他们就不会污染您的 DomainModel。
C) C 是你的控制器。这很像一个协调员。它从您的视图中获取数据，并确保它到达正确的后端函数/方法来处理该数据。它还协调从后端到前端的数据。
多层设计概念出现在表示层后面（MVC 主要在哪里）。当控制器从视图中获取数据并将其传递回后端时，它（如果您遵循 DDD 或域驱动设计）会将数据传递给应用程序服务（协调后端事务的类）。该服务可能会进一步将数据推送到存储库层（这是一个与数据库、文件系统、Web 服务等对话的类——任何基础设施的东西）。DDD 是一个很大的话题，但会让您了解 n 层方法以及它如何与 MVC 一起工作。
在研究这个主题时，看看 IoC（控制反转）、DI（依赖注入）、TDD（测试驱动开发）和尽可能多的模式（外观、工厂等）。
一般来说，业务逻辑不应该在控制器中——如果你遵循这种模式，你最终会得到大量的控制器。模型基本上包含所有非表示层……数据访问、业务逻辑和业务实体对象。您的控制器为视图准备业务数据。