1

如果您遵循官方 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 示例，而我在上面列出的代码是正确的做法？还是我完全偏离了这一切？

4

2 回答 2

5

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

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

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

这是故意非常抽象的。

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

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

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

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

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

于 2011-09-02T12:10:03.117 回答
1

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

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

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

于 2011-09-03T19:18:19.403 回答