1

如果你遵循官方型号胶文档,发现这里提供的快速入门指南:Coldfusion中的Model-Glue模型与其他MVC框架中的模型相同吗?

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

它会看起来像“模型”是执行的应用程序操作的类。在这个例子中,他们创建了一个Translator类,将一个短语翻译成Pig Latin。从这里很容易推断出程序逻辑也应该是“模型”,比如数据库操作类和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应该是一个对象,控制器会填充数据,然后将数据传递给视图,视图将其用作强类型对象来呈现数据。这意味着,对于上面提供的模型胶水例如,应该已经是一个翻译控制器,一个翻译视图,一个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的一个不好的例子,上面列出的代码是正确的做法?还是我完全偏离了这一切?

回答

5

我想也许你陷入了执行的细节之中。

我的(普通)MVC的理解如下:

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

这是故意非常抽象的。

我认为MG文档中的例子适当地实现了这个,虽然这个例子很有意思。控制器调用处理数据的模型(将输入转换为输出),然后设置结果。控制器然后调用接收数据并显示它的视图。

我不同意这个问题的前提“使用MVC,我该如何设计视图,以便它不需要知道控制器设置的变量?”该视图不应该关心数据来自哪里,它应该知道它需要什么数据,并从[某处]抓取它。在系统中需要有一个约定,该模型将数据用于某处,并且视图从某处获得它需要的数据(否则它可能会如何工作?);解耦是模型只是将数据放在被告知的位置,而视图只是从被告知的位置获取数据。控制器(或正在使用的MVC系统的惯例)决定了如何实现。我不认为MG在处理这种方式方面违背了MVC的任何原则。

就此陈述而言“在这种情况下,PigLatinTranslator仅仅是一个驻留在某处的类,不能被视为模型,控制器或视图。”那么......是的......所有的模型IS都是一些代码。所以PigLatinTranslator.cfc在这里模拟业务逻辑。

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

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

+0

我认为他的意思是“强类型”是视图可能期望一个用户对象,所以没有其他对象会工作。如果视图期望用户并收到一辆车,那么它很可能会抛出错误。从技术上讲,如果任何其他对象具有完成视图所需的所有属性和方法所需的任何其他对象,并且不会抛出错误,所以我认为它仍然不是真正强类型的。但是,我想我可以看到OP的来源。 –

+0

对不起 - 是的 - 这是真的,我在那里糟糕的表达自己。我甚至没有评论正确的事情,反思(我处于太多事情的中间,失去了我的想法)!OP指出的链接是讨论特定于C#/ MS的MVC系统;关于强类型视图数据的考虑是特定于此的,因此与MG无关。对不起,我没有注意到混乱。 –

+0

是的,我在这里挣扎的问题是,与ASP.NET MVC不同,ColdFusion不是强类型的。结果,视图使用魔术字符串将它需要的变量从'event'对象中拉出。我的问题是,该视图现在需要知道控制器将哪些变量放入'event'对象中,并且它好像打破了我所关心的问题。我认为这是不可避免的,该视图必须至少使用魔术字符串拉出某些东西,但我宁愿它是一个具有定义属性的CFC,而不是将数组和结构放入'event'对象中。 –

1

我认为MVC常见的混淆之一是有多个视图,多个控制器,但只有一个模型。 cfWheels对每个持久域对象都有一个“模型”对象,我认为这是非常令人困惑的 - 但是当然cfWheels是从Ruby on Rails中抽取出来的,它也在这种情况下使用了“模型”。

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

这也可能有助于思考视图需要的输入数据,因为它是“API”,并且它是控制器通过提供兼容数据来满足该API的工作。想一想,控制器需要知道什么类型的数据会满足视图而不是其他方式。

相关问题