提高MVC使用率

我忙於使用Kohana MVC框架在PHP中構建MVC應用程序，它工作得很好。但是我想解決一些小問題。提高MVC使用率

很多邏輯在控制器和控制器本身的動作之間重複。我一直在想它，我認爲定義一個包含這個共享邏輯的對象是明智的，所以它不會重複。

然後我聽說了一些播客和Preventing mission creep in your Views, or, ignorance is bliss的視圖模型。所以視圖模型就是我一直在尋找的東西。

但現在問題來了，你在視圖模型中放了什麼。我的想法是讓視圖模型收集相應視圖所需的所有信息。這具有以下優點：每個控制器/操作只需將輸入數據傳遞給視圖模型，然後將其傳遞給視圖。

這是一個聰明的主意嗎？在測試行爲上，將模型傳遞給視圖模型是明智的，因此可以嘲笑它。但我沒有真正使用模型。相反，我讓控制器通過Doctrine ORM訪問數據庫。將每個查詢翻譯爲單獨的方法似乎有點尷尬，但也許我錯過了一些東西。

從我聽說過的視圖模型來看，它們只是普通的DTO。但是，在動態弱類型語言中，這有什麼優勢呢？

也許我完全錯誤的軌道，應該做的不同。你對此有何想法？

編輯：

大多數我說的是收集正確的信息，並把它傳遞給正確的觀點的邏輯。

舉例：

我有一個客戶控制器。這些有兩個操作：添加和編輯。對於這兩項行動，我使用相同的觀點。在這兩個操作中，都分配了相同的視圖變量。在添加動作中，當表單無效時，輸入變量會再次傳遞給視圖。在編輯操作中，現有的值傳遞給低谷。這是我想要解決的一個大的重複。

來源

2009-12-23 Ikke

重複的邏輯表明需要進行某些重構，您不會說出那些關鍵字是什麼，所以我們無法確定您重構它的位置，但不要重複自己是一個有用的原則。所以原創的想法很好。我想知道從Controller到DB的直接交互（即缺少模型）是否是重複原因的一部分？

查看模型不止DTOs。它們包含（或指向）業務數據，並具有相關的解釋邏輯。在你參考的「任務蠕變」文章中，你會看到這個想法。視圖本身想知道是否顯示鏈接。該決定基於各種業務數據。您可以通過一個簡單的showLink（）方法將該邏輯放在一起。然後視圖可以專注於演示，viewModel可以專注於解釋。而且，同樣重要的是，實際的業務數據本身不知道該演示文稿。

來源

2009-12-23 09:28:13 djna

添加了一個示例。 – Ikke 2009-12-23 10:10:48

對不起，我不明白添加和編輯之間的重複，聽起來不像代碼是完全一樣的 – djna 2009-12-23 15:34:03

在前面的段落中關於控制器中的重複代碼解決您的擔憂......通過Kohana，我通常將通用控制器代碼放在基本控制器中，並從中繼承我的所有控制器。

例如，在一個項目中，我使用Template_Controller的修改版本來將每個頁面可用的Auth模塊引用爲$ this-> auth。

abstract class Template_Controller extends Controller { 

    /* @var Auth_Core reference to authorization class */ 
    protected $auth; 

    public function __construct() 
    { 
     parent::__construct(); 
     [snip] 
     $this->auth = new Auth(); 
    } 
[...] 
}

現在我所有的控制器是這樣開始的：這樣

class Help_Controller extends Template_Controller {

所有控制器訪問被$ this->權威性任何函數內。同意保留biz邏輯的觀點，這就是整個想法。

來源

2009-12-23 09:37:55

我已經有了這樣的設置。我有一個擴展模板控制器的應用程序控制器。並且每個其他控制器擴展應用程序控制器這麼多的共享邏輯已經集中在一個地方。 – Ikke 2009-12-23 09:52:58

提高MVC使用率

回答

相關問題