Coldfusion中的Model-Glue模型與其他MVC框架中的模型相同嗎？

如果你遵循官方型號膠文檔，發現這裏提供的快速入門指南：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的一個不好的例子，上面列出的代碼是正確的做法？還是我完全偏離了這一切？

來源

2011-09-02 Daniel T.

我想也許你陷入了執行的細節之中。

我的（普通）MVC的理解如下：

一些工作需要做
控制器定義了工作是如何完成的，以及它是如何呈現
控制器[某事]最終調用模型處理髮生
模型進程處理所有數據處理：從[某處]獲取數據，應用業務邏輯，然後將結果[某處]
控制器然後[執行某些操作]最終調用視圖處理，並利用視圖處理系統對來自模型的數據進行視圖處理，從而獲取他們期望的數據並將數據呈現給用戶。

這是故意非常抽象的。

我認爲MG文檔中的例子適當地實現了這個，雖然這個例子很有意思。控制器調用處理數據的模型（將輸入轉換爲輸出），然後設置結果。控制器然後調用接收數據並顯示它的視圖。

我不同意這個問題的前提「使用MVC，我該如何設計視圖，以便它不需要知道控制器設置的變量？」該視圖不應該關心數據來自哪裏，它應該知道它需要什麼數據，並從[某處]抓取它。在系統中需要有一個約定，該模型將數據用於某處，並且視圖從某處獲得它需要的數據（否則它可能會如何工作？）;解耦是模型只是將數據放在被告知的位置，而視圖只是從被告知的位置獲取數據。控制器（或正在使用的MVC系統的慣例）決定了如何實現。我不認爲MG在處理這種方式方面違背了MVC的任何原則。

就此陳述而言「在這種情況下，PigLatinTranslator僅僅是一個駐留在某處的類，不能被視爲模型，控制器或視圖。」那麼......是的......所有的模型IS都是一些代碼。所以PigLatinTranslator.cfc在這裏模擬業務邏輯。

而這個：「在其中一個答案中，有人提到MVC中的」模型「應該是控制器用數據填充的對象，然後將數據傳遞給視圖」...我不'我認爲這是正確的。控制器只是在討論需要調用哪些模型和哪些視圖來滿足需求，並且可能會在它們之間交換數據（儘管這也可以按慣例來完成）。控制器不做數據處理;它決定哪些數據處理需要完成。

最後，我不認爲「強類型」評論在CF環境中是相關的或適宜的考慮，因爲CF沒有強類型。這是一個特定於平臺的考慮因素，與MVC原則無關。

來源

2011-09-02 12:10:03

我認爲他的意思是「強類型」是視圖可能期望一個用戶對象，所以沒有其他對象會工作。如果視圖期望用戶並收到一輛車，那麼它很可能會拋出錯誤。從技術上講，如果任何其他對象具有完成視圖所需的所有屬性和方法所需的任何其他對象，並且不會拋出錯誤，所以我認爲它仍然不是真正強類型的。但是，我想我可以看到OP的來源。 –

對不起 - 是的 - 這是真的，我在那裏糟糕的表達自己。我甚至沒有評論正確的事情，反思（我處於太多事情的中間，失去了我的想法）！OP指出的鏈接是討論特定於C＃/ MS的MVC系統;關於強類型視圖數據的考慮是特定於此的，因此與MG無關。對不起，我沒有注意到混亂。 –

是的，我在這裏掙扎的問題是，與ASP.NET MVC不同，ColdFusion不是強類型的。結果，視圖使用魔術字符串將它需要的變量從'event'對象中拉出。我的問題是，該視圖現在需要知道控制器將哪些變量放入'event'對象中，並且它好像打破了我所關心的問題。我認爲這是不可避免的，該視圖必須至少使用魔術字符串拉出某些東西，但我寧願它是一個具有定義屬性的CFC，而不是將數組和結構放入'event'對象中。 –

我認爲MVC常見的混淆之一是有多個視圖，多個控制器，但只有一個模型。 cfWheels對每個持久域對象都有一個「模型」對象，我認爲這是非常令人困惑的 - 但是當然cfWheels是從Ruby on Rails中抽取出來的，它也在這種情況下使用了「模型」。

一般來說，在MVC中，「模型」代表您的業務數據和邏輯作爲一個整體。該模型由許多域對象（通常是持久性的）和許多服務對象（其存在用於編排跨多個域對象的操作）組成。在現實世界的應用程序中，通常有一個數據層管理域對象的持久性 - 可以通過多種方式進行分區。

這也可能有助於思考視圖需要的輸入數據，因爲它是「API」，並且它是控制器通過提供兼容數據來滿足該API的工作。想一想，控制器需要知道什麼類型的數據會滿足視圖而不是其他方式。

來源

2011-09-03 19:18:19

Coldfusion中的Model-Glue模型與其他MVC框架中的模型相同嗎？

回答

相關問題