2011-01-11 77 views
13

我正在開始「學習MVC」的方式。基本上,我沒有面向對象編程的大問題,但是有一個技術方面需要澄清。看來我的理論還不夠好。控制器與模型 - 需要說明

目前,我使用KohanaPHP框架,第3版。

示例情況: 我有一個網站,在那裏用戶可以提交文章。

所以,我有以下結構:

classes/ 
    /controllers/ 
     article.php 
    /models/ 
     articles.php 

到目前爲止好。我沒有模型擴展Kohana_Model的問題,但我不確定我是否使用了正在使用ORM的正確方式模型。

基本上,當使用模型擴展Kohana_Model時,我會把所有的邏輯操作放在模型中。我應該對使用ORM的模型執行相同的操作嗎?在網上的很多例子中,我看到控制器對用戶輸入/數據進行邏輯操作,這在我看來是不正確的。

比方說,我需要從數據庫中獲得幾行,所以我在模型中創建適當的方法並返回對象。我認爲這是正確的,不是嗎?

基本上,所有對用戶輸入/數據的操作(從db中選擇,插入db,驗證)我放入模型中。這就是我理解MVC設計模式的方式。模型應該關心所有「機械」操作,控制器只是模型/視圖之間的「橋樑」,而且它是一個「前端」引擎。

這是一個正確的方法嗎?

我知道這對於更高級的用戶來說可能是一個愚蠢的問題,但我只想學習最佳實踐。如果任何人可以提供一些澄清,我會很高興。

+0

這不是一個愚蠢的問題。該主題只是混淆,因爲原來的[MVC模式不匹配web應用程序中的處理](http://stackoverflow.com/questions/1549857/simple-php-mvc-framework/1549970#1549970)。所以不要試圖找到「正確」的方法。通常最適合使用類似PMVC的結構,其中模型僅僅是未知的數據庫接口。 – mario 2011-01-11 10:12:33

回答

41

總之而言,你的模型對數據進行的所有操作中找到(無論是傳入,傳出,數據庫,文件...數據),您的視圖應該照顧顯示數據。控制器應該調用必要的模型方法來使數據準備好傳遞給視圖。控制器不應對數據執行任何更改,但應對其進行測試以正確完成必要的操作。

希望我已經說得夠清楚了,讓我知道如果這不能爲你解決問題。

2

我沒有使用KohanaPHP,但它看起來像一個'軌道啓發'框架。 在鋼軌領域,通常認爲最好的做法是使用瘦身控制器和胖模型。

一些背景可這個老文章了Jamis降壓http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model或在這其中涉及的CakePHP http://gluei.com/blog/view/cakephp-best-practices-fat-models-and-skinny-controllers

+0

感謝您的回答。我要去選擇poelinca的答案是正確的(你的答案也是正確的),但你得到更多的分數;-) – 2011-01-11 10:28:07

+0

嘿,不再; – roman 2011-01-11 10:31:17

1

從數據中分離邏輯的想法是,數據不包含邏輯,所以在你的模型中,你應該只是真正的消毒數據。

拿這個例子:

public class Articles extends MasterModelLayer 
{ 
    public function create($title,$text,$user_id = false) 
    { 
     if(!$user_id) 
     { 
      $user_id = get_guest_id(); 
     } 
     //Insert 
    } 
} 

似乎在模型中合法的邏輯,但是從現在開始,您的應用程序必須能夠讓客人發表文章,或者它有缺陷的,你需要編輯模型,然後將地板上的其他應用程序/網站

領域採取這樣的場景:

你有2個站點

  • ComputerArticles.com
  • CookingArticles.com

現在這兩個域名指向同一個服務器,但在kohona一個單獨的應用程序,可以不把你的模型中的任何域邏輯您可以使用精確的樣本模型橫跨您的所有域名。

你的模型方法應該像這樣:

public class Articles extends MasterModelLayer 
{ 
    public function create($title,$text,$user_id) 
    { 
     $this->compile("articles",array($title,$text,$user_id))->insert(); 
    } 
} 

而且你的控制器內,你應該把所有的邏輯,邏輯將取決於域。

將您的模型看作是一個API,其中您有多個使用相同API的站點但使用不同的邏輯。

希望這會有所幫助。

0

下面是術語的基本外行定義 - 瀏覽:呈現給用戶 控制器的屏幕:發動機/框架,它發生在請求,決定誰處理,並適當地代表他們。 型號:這基本上告訴你什麼屏幕顯示後,所以在這個屏幕上完成操作。把它想成一個(定向)圖。從節點出現的邊緣是動作,它們連接的節點是基於這些動作的下一個屏幕。

因此,一個模型基本上包括用戶在屏幕及其動作處理程序上執行的操作。控制器簡單地調用相應的動作處理程序來處理特定的用戶動作,動作處理程序負責對傳入的請求進行一些合理的處理。

現在你的問題。業務邏輯在哪裏? 嗯,它是行動處理程序。或者它被抽象到人們喜歡稱之爲業務層的地方。但無論如何,它是從行動處理者本身引發的。

因此,在技術上,業務邏輯是其本身是模型一部分的一部分行爲。 如果您這樣認爲,這是有道理的:控制器處理用戶交互並基於模型(操作+業務)呈現視圖。

**錯誤更正。