2012-01-11 52 views
3

如果您使用的是MVC建立一個用戶配置文件,那會是最好有使用模型或控制器這樣的功能內製定出評論的顯示類型的條件語句:條件語句是否屬於模型或控制器中的一個php mvc?

例如 我有3類

  • 評論
  • 會員
  • 管理員(延伸部件)

一些示例使用的僞代碼,其中功能缺失

選項1

相關的用戶登錄的showComments函數返回的意見將還給不同的信息類型。

class user { 

    function isLoggedIn() { //Check if a user is logged in } 

    function getUserType() { // return user type } 

    function showComments($id) { //comments code } 
} 

class admin extends user { 
    function showComments($id) { //comments code } 
} 

然後使用控制器內的代碼來確定依賴於登錄的用戶類型顯示?

$profileContent = $user->getOtherContent(); 

if ($user->isLoggedIn() && $user->getUserType() == "member") { 
    $member = new member(); 
    $comments = $member->showComments($profileId); 
} 
elseif ($user->isLoggedIn() && $user->getUserType() == "admin") { 
    $admin = new admin(); 
    $comments = $admin->showComments($profileId); 
} 
else 
    $comments = $user->showComments($profileId); 

require 'templates/profile.php'; 

選項2

由於這是一個自定義的框架,我可以在模型內的所有內容移動到一個功能,並在用戶的一個函數來檢查的註釋類型顯示:

abstract class user { 

    function isLoggedIn() { //Check if a user is logged in } 

    function getUserType() { // return user type } 

} 

class profile { 

    function showComments($profileId, $user) { 

     if (User::isLoggedIn() && User::getUserType() == "member") { 
      $comments = //database query and formatting for member 
     } 
     elseif (User::isLoggedIn() && User::getUserType() == "admin") { 
      $comments = //database query and formatting for admin 
     } 
     else 
      $comments = //database query and formatting for guest 

     return $comments; 
    } 
} 

使用類似的控制器:

$profile = new profile($profileId); 
$comments = $profile->showComments(); 

require 'templates/profile.php'; 
+0

您是否使用特定的框架?你提到你有一個模型和控制器,但是一個視圖呢? – Kekoa 2012-01-11 18:37:15

+0

哎呦我錯過了那部分,在控制器中的if/else之後需要視圖。評論以「$ comments」的形式傳給它。 – Dan 2012-01-11 18:41:12

+0

對於你所要求的內容沒有規定,所以盡一切可能爲你做。 – hakre 2012-01-11 18:43:58

回答

5

從技術上講,兩者都是正確的。 MVC模式是故意抽象的,並且關於模型與控制器的適當領域有什麼爭論。

根據您使用的確切框架,可能有一個「更好」的答案。否則,做你認爲最有意義的事情。

更新 - 在改變你的問題,我想定製我的回答有點輕:

對於選項1會更有感覺來設計模型,像這樣:

class user { 
    function isLoggedIn() {} 
    function getUserType() {} 
    function showComments() {} 
} 

class admin extends user { 
    function getUserType() {} 
    function showComments() {} 
} 

class member extends user { 
    function getUserType() {} 
    function showComments() {} 
} 

在控制器中,$ user應該作爲管理員,成員或用戶來實例化(這可以通過靜態工廠或直接在控制器中完成)。您的控制器僅僅是

if ($user->isLoggedIn()) { 
    $comments = $user->showComments($profileId); 
} 

後(爲了使這更聰明,簡檔可以被設置爲一個類屬性(除非用戶有多個配置文件?)

選項2,OTOH,是一個聰明的利用模型到模型的設計

我看到的唯一真正的區別是你如何概念化評論你認爲他們是用戶的一部分(與簡介關係薄弱)?還是部分簡介(與用戶之間的聯繫較弱)?這兩種方法都沒有讓我看到蝙蝠的任何特殊痛點,所以最好的選擇是運行一個能夠使用最多的給你。

+2

+1框架很重要,因爲他們通常傾向於將意見融入他們自己的「最佳實踐」 – Kekoa 2012-01-11 18:46:54

2

我相信這屬於模型。我認爲用戶身份驗證和驗證不屬於控制器,最終它正在驗證數據以及在模型中完成的MVC。

我不認爲這是一個很好的適合控制器的另一個原因。這太聰明瞭。控制器應該只知道它需要向視圖提供一些評論。爲什麼控制器需要知道什麼類型的用戶登錄?它不應該,它應該只知道模型說它應該有的數據。

2

我嘗試將處理數據(檢索,操作等)的任何邏輯移動到模型中。有時包括條件陳述。個人而言,我會爲User類製作「showComments」和實例方法,但這確實是一個意見問題(也被強烈意見的人稱爲「最佳實踐」)。

我傾向於採用Fat Model, Skinny Controller的方法,看起來很謹慎。

+0

showComments如果知道用戶是哪種類型的用戶,它會如何完成?我有點卡住了,因爲我用其他方式編碼,因爲我的思想現在已經設定了這種方法,而我無法從另一個方向看到它會更好地套用它嗎? – Dan 2012-01-11 19:02:03

+0

這取決於你使用的是什麼框架。如果您正在從數據庫記錄實例化用戶,則用戶應該有一個與其關聯的ID。像$ userComments = findComments($ this-> ID);希望這是有道理的(可能不是)。 – 2012-01-11 19:07:46

+0

我已更新問題,選項2現在顯示更多我認爲你的意思? – Dan 2012-01-11 19:28:51

1

業務邏輯屬於控制器。數據邏輯屬於模型。

因此,如果您需要根據用戶輸入顯示某些數據,則屬於控制器。但是,實際獲取/存儲數據屬於模型。

+0

因此,調用一個構建類以獲取該頁面所需的所有數據,而不是調用每個類從控制器獲取相同的數據?第二種方法只是控制器會有更多的代碼? – Dan 2012-01-14 22:54:19

2

我想這一切都來自你的模型/視圖/控制器代表什麼。這裏是我的2美分:

型號

模型應該處理一個只有一個應用程序邏輯。如果您有用戶模型,那麼在該模型中應該只有與用戶相關的方法和屬性。也就是說,如果可能的話,儘量不要在用戶模型中有評論邏輯。它們屬於評論模型。在當前模型中調用另一個模型的條件將成爲應用程序另一部分的交叉。這就是控制器的用途。

模型應始終以抽象結構響應。模型不應該以格式化或基於字符串的格式進行響應。它通常應該是一個數組,一個對象,一個簡單的int(最好是一個模型常量)或一個布爾值。

控制器

控制器應處理的輸入數據(即使一個普通網頁視圖是輸入數據),並且基於該數據,它應該調用一個應用程序邏輯。

在您的控制器中,您應該擁有與調用一個或另一個模型相關的所有條件。

基於抽象結果,它應該調用另一個模型,或者收集響應併合並它,以便它可以作爲簡單結構傳遞到視圖(儘量不要將對象傳遞到視圖,但是如果你是面臨複雜的結構作爲模型返回值,將它們收集到一個數組中並將其傳遞給視圖)。

查看

的看法是三個最直截了當。它應該已經格式化簡單的指令響應剛剛處理顯示(或在某些情況下,控制器的串行或改造由另一個應用程序的響應弄成可見 - 瀏覽器,或第三的應用程序調用API)


這一切都歸結於MVC架構的喘息。儘量在整個項目中保持一個不斷髮展的「策略」。

希望它有幫助

相關問題