Cold聚变中的model模型是否与其他MVC框架中的模型相同？

Question

如果您遵循官方Model-Glue docs提供的快速启动指南，请在这里找到：

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

看起来，“模型”是一个执行应用程序操作的类。在本例中，他们创建了一个Translator类，该类将一个短语转换为Pig拉丁语。从这里可以很容易地推断出程序逻辑也应该是“模型”，例如数据库操作类和HTML助手。

但是，最近我在这里问了一个关于MVC的问题，得到了一个答案：

Using MVC, how do I design the view so that it does not require knowledge of the variables being set by the controller?

在其中一个答案中，有人提到MVC中的“模型”应该是控制器填充数据的对象，然后数据传递给视图，视图使用它作为强类型对象来呈现数据。这意味着，对于上面提供的model示例，应该有一个翻译器控制器、一个翻译器视图、一个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模型-Glue的模型与MVC模型不同吗？或者他们提供的快速启动指南是MVC的一个糟糕的例子，我上面列出的代码是正确的吗？还是我在这一切上完全偏离了方向？

Answer 1

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

我对MVC (一般)的理解如下：

• 需要做一些工作--控制器定义了该工作是如何完成的，控制器如何进行
• --控制器最终调用模型处理来实现
• --模型进程处理所有数据:从某个地方获取数据，应用业务逻辑，然后将结果放到
• 的某个地方，然后控制器做一些最终调用视图处理的事情，并利用来自模型的数据的视图处理系统&H 210H 111视图进程以某种方式获取他们期望的数据，并以某种方式呈现这些数据。H 212

这是故意非常抽象的。

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

我不同意这个问题的前提：“使用MVC，如何设计视图，使其不需要了解控制器设置的变量？”视图不应该关心数据来自何处，它应该知道它需要什么数据，并从某个地方获取数据。系统中确实需要有一种约定，即模型将数据放在某个地方，而视图从某个地方获取它需要的数据(否则它可能如何工作？)；脱钩的是，该模型只将数据放在被告知的位置，而视图只从告诉它的位置获取数据。控制器(或使用中的MVC系统的约定)指示如何实现这一点。我不认为MG在处理这个问题时破坏了MVC的任何原则。

就这条语句而言，“在本例中，PigLatinTranslator只是一个驻留在某处的类，不能被视为模型、控制器或视图”。好吧..。嗯..。一个模型就是一些代码。因此，PigLatinTranslator.cfc在这里对业务逻辑进行建模。

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

最后，我不认为“强类型”的评论在CF环境中是相关的，也不是一个重要的考虑因素，因为CF不是强类型的。这是一个特定于平台的考虑，与MVC原则无关。

Answer 2

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

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

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