如果您遵循Model-Glue官方文档提供的快速入门指南，可以在这里找到:
http://docs.model-glue.com/wiki/QuickStart/2%3AModellingourApplication Quickstart2: ModelingourApplication
看起来"模型"是一个执行应用程序操作的类。在这个例子中，他们创建了一个Translator类，将一个短语翻译成Pig Latin。从这里很容易推断出程序逻辑也应该是"模型"，比如数据库操作类和HTML helper。
然而，我最近收到了一个关于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示例，而我上面列出的代码是正确的方法?还是说我完全偏离了方向?
我想你可能在实现的细节上陷入了困境。
我对MVC(一般)的理解如下:
- 有些工作需要完成
- 控制器定义了工作是如何完成的，以及它是如何呈现的
- 控制器[做某事]最终调用模型处理发生
- 模型进程处理所有数据处理:从[某处]获取数据，应用业务逻辑，然后将结果放在[某处]
- 控制器然后[做一些事情]，最终调用视图处理发生，并利用来自模型的数据的视图处理系统
- 视图进程获取它们期望的数据，并以某种方式呈现该数据。
故意很抽象。
我认为MG文档中的例子适当地实现了这一点，尽管这个例子很做作。控制器调用处理数据的模型(将输入转换为输出)，然后设置结果。然后控制器调用获取数据并显示数据的视图。
我不同意这个问题的前提"使用MVC，我如何设计视图，使它不需要控制器设置的变量的知识?"视图不应该关心数据来自哪里，它只应该知道它需要什么数据，并从[某处]获取数据。在系统的某个地方确实需要有一个约定，即模型将要使用的数据放在某个地方，视图从某个地方获得所需的数据(否则它怎么可能工作?);解耦就是模型把数据放在被告知的地方，视图从被告知的地方得到数据。控制器(或使用中的MVC系统的约定)规定了如何实现它。我不认为MG在处理这个问题的方式上违反了MVC的任何原则。
就这句话而言，"在这种情况下，PigLatinTranslator仅仅是一个驻留在某处的类，不能被视为模型、控制器或视图。"嗯…是的…所有的模型都是一些代码。所以PigLatinTranslator。CFC在这里对业务逻辑进行建模。
这个:"在其中一个答案中，提到MVC中的"模型"应该是控制器用数据填充的对象，然后传递给视图"…我认为那是不对的。控制器只是处理需要调用哪些模型和哪些视图来满足需求，并可能在它们之间交换数据(尽管这也可以通过约定来完成)。控制器不做数据处理;它决定需要进行哪些数据处理。
最后，我不认为"强类型"注释在CF环境中是相关的或适当的考虑，因为CF不是强类型的。这是特定于平台的考虑，与MVC原则无关。
我认为围绕MVC的一个常见混淆是有多个视图，多个控制器，但只有一个模型。cfWheels对每个持久化域对象都有一个"模型"对象，我认为这是非常令人困惑的——但cfWheels当然是从Ruby on Rails中绘制的，在该上下文中也使用了"模型"。
一般来说，在MVC中，"模型"作为一个整体表示您的业务数据和逻辑。模型由许多域对象(通常是持久的)和许多服务对象(存在的目的是跨多个域对象编排操作)组成。在实际应用程序中，通常有一个数据层来管理域对象的持久性——可以用多种方式对其进行分区。
还可以将视图需要的输入数据视为"API"，而控制器的工作是通过提供兼容的数据来满足该API。控制器需要知道什么类型的数据将满足视图，而不是相反。