模型不应该只描述将从控制器传递到视图的数据吗？这难道不会使弱类型语言中的模型变得不必要吗？在PHP中，他们在模型中进行DB工作，但这不是错的吗？在我看来，模型在弱类型语言中是不必要的。。。
对术语模型有一些误解。Microsoft的MVC3框架具有视图模型的概念，它只是用于渲染视图的数据。然而，这并不是M在MVC中所代表的确切含义。该模型包括您的业务实体。我们有瘦控制器和胖模型，但有非常瘦的视图模型。我们的控制器对执行业务逻辑的服务进行调用，而控制器自己从不执行此逻辑。然后，我们转换我们的业务实体（数据模型），并将它们转换为可用于渲染视图的轻量级视图模型。
所以为了回答你的问题
模型不应该仅仅描述将从控制器传递到视图的数据吗？
那么，也许你真正想问的是，视图模型不是没有必要吗？我不知道你为什么这么想。视图模型+视图生成结果。在PHP中，定义一个具有易于访问的属性的类是很有帮助的。这对于澄清您的期望是明智的，可以防止您调用具有超长集合或参数的方法。在JavaScript中，不需要定义视图模型，只需将属性推送到一个新对象上，并将其与视图一起传递给视图渲染逻辑。这更多地反映了这些语言使用的OO模式，而不是它们是弱类型的。
如果您在问模型是否是不必要的，那么您就错过了MVC体系结构的目的。MVC的一个重要部分是将您的关注点分开。为什么要对代码应用任何体系结构？我相信你可以找到比我能给你的更好的解释MVC背后的动机。
模型是一个有用的概念工具，即使在PHP中并不严格需要将其与DB代码分离。例如，您可以将一个数据对象与封装一些业务逻辑的每个表关联，或者定义一组业务实体，将表间的数据聚合为控制器可以使用的域特定对象，或者只有一个拥有所有访问功能并返回实体的怪物DB对象。与控制器直接使用DB代码相比，这具有明显的优势：
- 如果您正在定义跨DB表运行的复杂数据结构，由于存在重复的风险，您不希望在控制器代码中这样做——最好有一个单一的定义来强制整个系统的一致性。尽管这可能会引入依赖关系，但有一个定义数据的函数/对象可以很容易地找到数据的使用位置，以便修复问题
- 如果有一个地方可以找到所有数据结构定义，那么第三方维护要容易得多
- 如果您可以交换整个模型或其中的一部分，并将其替换为将提供测试数据的模拟对象，那么单元测试就更容易了
- 它使控制器更轻，因此可读性和可维护性更强
所以你可以争辩说这没有必要，但它有很大帮助。
我一直将模型视为提供数据的工具。这意味着您的控制器永远不必担心数据源，如果您想从使用数据库切换到XML文件，那么您只需要交换您的模型。
只要你有一些数据提供者抽象。一些模型将进行低级别验证（与存储引擎紧密耦合-空检查等），但控制器"应该"进行所有业务逻辑/验证。
我个人有一个类似瘦结构的类，它映射到每个表（都实现IDataStruct）。此结构或其集合是唯一在DomainObject和DataProvider之间移动的对象。然后，我可以通过接口强制执行我应该接收的数据结构。这不是一个银弹，但我发现它工作得很好（使缓存和单元测试等事情变得很容易）
我希望这不会混淆问题。