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