Model-Glue在Coldfusion中的模型和其他MVC框架中的模型一样吗？

Question

如果您遵循 Model-Glue 官方文档提供的快速入门指南，请在此处找到：

http://docs.model-glue.com/wiki/QuickStart/2%3AModellingourApplication#Quickstart2:ModelingourApplication

看起来“模型”是执行应用程序操作的类。在此示例中，他们创建了一个 Translator 类，用于将短语翻译成 Pig Latin。从这里很容易推断出程序逻辑也应该是“模型”，例如数据库操作类和HTML帮助器。

然而，我最近收到了我在这里提出的有关 MVC 的问题的答案：

使用 MVC，如何设计视图，使其不需要了解所设置的变量 在其中一个答案中，有人提到MVC中的“模型

”应该是一个对象，控制器用数据填充该对象，然后将其传递给视图，视图将其用作用于呈现数据的强类型对象。这意味着，对于上面提供的 Model-Glue 示例，应该有一个翻译器控制器、一个翻译器视图、一个 PigLatinTranslator 类，以及一个看起来像这样的 Translation 模型：

component Translation
{
    var TranslatedPhrase = "";
}

该控制器将像这样使用它：

component TranslatorController
{
    public function Translate(string phrase)
    {
        var translator = new PigLatinTranslator();
        var translation = new Translation();
        translation.TranslatedPhrase = translator.Translate(phrase);

        event.setValue("translation", translation);
    }
}

并且视图将像这样渲染它：

<p>Your translated phrase was: #event.getValue("translation").TranslatedPhrase#</p>

在这种情况下，PigLatinTranslator 只是一个驻留在某处的类，以及不能被视为模型、控制器或视图。

我的问题是，ColdFusion Model-Glue 的模型与 MVC 模型不同吗？或者他们提供的快速入门指南是一个糟糕的 MVC 示例，而我上面列出的代码是正确的方法吗？或者我完全偏离了这一切？

Answer 1

我认为您可能陷入了实施细节的困境。

我对（一般）MVC 的理解如下：

• 需要完成一些工作
• 控制器定义如何完成该工作以及如何呈现
• 控制器[做某事]最终调用模型处理以进行
• 模型处理句柄所有数据处理：从[某处]获取数据，应用业务逻辑，然后将结果放在
• 控制器[某处]，然后[做某事]，最终调用视图处理进行，并利用来自模型的数据的视图处理系统
• 视图进程抓取数据他们期待并以某种方式呈现该数据。

这是故意非常抽象的。

我认为 MG 文档中的示例适当地实现了这一点，尽管该示例非常人为。控制器调用处理数据的模型（将输入转换为输出），然后设置结果。然后控制器调用获取数据并显示数据的视图。

我不同意这个问题的前提“使用 MVC，我如何设计视图，以便它不需要了解控制器设置的变量？”视图不应该关心数据来自哪里，它应该只知道它需要什么数据，并从[某处]获取它。系统中确实需要有一个约定，模型将要使用的数据放在某个地方，视图从某个地方获取它需要的数据（否则它怎么可能工作？）；解耦是模型只是将数据放在被告知的地方，而视图只是从被告知的地方获取数据。控制器（或正在使用的 MVC 系统的约定）决定了如何实现。我不认为 MG 处理这个问题的方式违反了 MVC 的任何原则。

就这个说法而言，“在这种情况下，PigLatinTranslator 只是一个驻留在某处的类，不能被视为模型、控制器或视图。”嗯...是的...所有模型都是一些代码。因此 PigLatinTranslator.cfc 在这里对业务逻辑进行建模。

而这个：“在其中一个答案中，有人提到 MVC 中的“模型”应该是控制器用数据填充的对象，然后将其传递给视图”......我不认为这是正确的。控制器只是争论需要调用哪些模型和哪些视图来满足要求，以及它们之间可能的数据交换（尽管这也可以按照惯例完成）。控制器不进行数据处理；它决定需要进行哪些数据处理。

最后，我不认为“强类型”注释在 CF 环境中是相关的或适当的考虑因素，因为 CF 不是强类型的。这是特定于平台的考虑因素，与 MVC 原则无关。

Answer 2

我认为 MVC 的常见困惑之一是有多个视图、多个控制器，但只有一个模型。 cfWheels 对于每个持久域对象都有一个“模型”对象，我认为这非常令人困惑 - 但当然 cfWheels 是从 Ruby on Rails 中提取的，它也在该上下文中使用“模型”。

一般来说，在 MVC 中，“模型”代表整个业务数据和逻辑。该模型由许多域对象（通常是持久性的）和许多服务对象（其存在是为了协调跨多个域对象的操作）组成。在现实世界的应用程序中，您通常有一个数据层来管理域对象的持久性 - 可以通过多种方式进行分区。

它还可能有助于将视图所需的输入数据视为“API”，并且控制器的工作是通过提供兼容的数据来满足该 API。更多地认为控制器需要知道什么类型的数据将满足视图而不是相反。