MVC架构和弱类型语言(例如PHP)是不必要的模型吗？

Question

模型不应该只描述从控制器传递到视图的数据吗？这不是让弱类型语言中的模型变得不必要了吗？在PHP中，他们在模型中做数据库工作，但这不是错误的吗？在我看来，模型在弱类型语言中是不必要的……

Answer 1

对术语模型有一些误解。微软的MVC3框架有视图模型的概念，它只是你用来呈现你的视图的数据。然而，在MVC中，这并不完全是M所代表的。该模型包括您的业务实体。我们有瘦控制器和胖模型，但视图模型非常薄。我们的控制器调用执行业务逻辑的服务，而控制器本身从不执行此逻辑。然后，我们转换业务实体(数据模型)并将其转换为轻量级视图模型，该模型可用于呈现视图。

所以我来回答你的问题

不应该只描述从控制器传递到视图的数据吗？

那么也许你真正想问的是视图模型不是不必要的吗？我不知道你为什么会这么想。视图模型+视图就是结果。在PHP中，定义一个具有易于访问的属性的类会很有帮助。这对于澄清您的期望是明智的，并防止您调用具有可怕的长集合或参数的方法。在JavaScript中，不需要这样定义视图模型，您只需将属性推送到新对象上，并将其与视图一起传递给视图呈现逻辑。这更多地反映了这些语言使用的OO模式，而不是它们是弱类型的事实。

如果你问模型是否是不必要的，那么你就错过了MVC架构的目的。MVC的很大一部分是将你的关注点分开。为什么要对你的代码应用任何架构呢？我相信你可以找到比我给你更好的解释MVC背后的动机。

Answer 2

模型是一个有用的概念工具，即使在PHP中没有严格的必要将其与DB代码分开，例如，您可以将数据对象与封装了一些业务逻辑的每个表相关联，或者定义一组业务实体，将表中的数据聚合到控制器随后可以使用的特定于域的对象中，或者只有一个具有所有访问函数并返回实体的怪物DB对象。与直接由控制器使用DB代码相比，这具有明显的优势：

• 如果您正在定义跨DB表运行的复杂数据结构，则由于存在重复的风险，您不希望在控制器代码中执行此操作-最好使用单一定义来强制整个系统保持一致性。尽管这会引入依赖关系，但拥有一个定义数据的函数/对象可以更容易地找出数据的使用位置，以便您可以进行修复。如果有一个地方可以找到所有数据结构定义的位置，那么
• 第三方维护就会容易得多。
• 如果您可以交换出整个或部分模型，并将其替换为将提供测试数据的模拟对象，则单元测试将变得更容易。
• 它使控制器更轻，因此更具可读性和可维护性

所以你可能会说这不是必要的，但它有很大的帮助。

Answer 3

我一直将模型视为提供数据的工具。这意味着您的控制器永远不必担心数据源，如果您想从使用数据库切换到XML文件，那么您只需交换您的模型。