松散耦合的MVC的替代方案？

Question

我作為PHP程序員在網上商店工作。 大多數情況下，我們使用良好的編碼實踐，但整個網站的結構不多。

我現在已經進入了對我們的一些實踐感到厭倦的階段，並希望以一種有用的方式擴展和簡化並生成一些東西，不僅對我而言，還有辦公室中的混合程序員Web開發人員。

一位員工給我們留下了一個用PHP編寫的MVC網站，我不得不維護它，我得到了它的工作方式，但有我的抱怨，我的主要抱怨是它與每件依賴於另一件的緊密耦合。 我看到了分離問題的優勢，但除了我看代碼之外，這對任何人來說都會讓人感到困惑。

因此，例如，如果我需要向網站添加新頁面，我必須添加視圖，然后添加模型，然后更新控制器。 制作新頁面的特殊方法比這簡單，並且不需要程序員。

我的判斷是，這是一個更好的方法來構建，而不是維護一個網站。

不過，如果我有一些設計模式，我可以有效地重用代碼，而不依賴於網站中的多個位置，那將是很好的。

所以我的問題是，是否有一種用於構建和維護更松散耦合的網站的設計模式？ 我不是在尋找MVC上的細微變化，我需要看一些不同的東西，也許某種類型的插件方法。

編輯：

謝謝你到目前為止的答案！ 一種不同的方式是我希望代碼在我的辦公室里做得更好。 做IA）推動MVC或B）找到/構建一個替代方案，而不是讓半程序員感到困惑。 我們已經使用類來連接數據庫連接和表單幫助。 這個問題的關鍵是探索B.

Answer 1

在代碼混亂之間總是存在折衷，因為它是高度解構主義者，並且代碼令人困惑，因為完全需要做X的一切都是隨機分散在一個文件周圍。

后者的問題在於，究竟什么是將事物分解成單片模塊的“直觀”方式因人而異。 高度分解和分解代碼幾乎總是更難以解決，但一旦你這樣做，維護變得容易做。 我不同意除了作者看到它之外，其他任何人都會感到困惑。 使用像MVC這樣的大范圍模式，因為隨着時間的推移，更容易發現它們並處理圍繞它們構建的項目。

使用MVC的另一個好處是，如果您不堅持使用分層，通常不會使應用程序更難以維護。 這是因為現在您有一個預定的位置可以放置實現新功能的任何方面。

就考慮緊耦合而言，如果層之間沒有某種連接，則無法實現功能。 松散耦合並不意味着層完全相互無知 - 這意味着層應該不知道其他層是如何實現的。 例如：控制器層不關心您是使用SQL數據庫還是只編寫二進制文件來在數據訪問層保留數據，只是有一個數據訪問層可以為它獲取和存儲模型對象。 它也不關心你是否在視圖層使用原始PHP或Smarty，只是它應該為某些預定的名稱提供一些對象。 視圖層甚至不需要知道有一個控制器層 - 只有它被調用，數據才能在/ something /提供的上述名稱下顯示。

Answer 2

隨着框架模板的發展，我發現MVC模式是構建應用程序最“松散耦合”的方式之一。

想想接口之類的關系，或者應用程序各部分之間的契約。 模型承諾將此數據提供給View和Controller。 沒有人關心模型如何做到這一點。 它可以從典型的DBMS（如MySQL），平面文件，外部數據源（如ActiveResource）讀取和寫入，只要它完成交易的結束即可。

Controller承諾向View提供某些數據，並依賴Model來履行其承諾。 視圖不關心Controller是如何做到的。

View假設模型和控制器將遵守其承諾，然后可以在真空中開發。 模型和控制器不關心視圖是否生成XML，XHTML，JSON，YAML，明文等。它們正在阻止它們的合同結束。

當然，視圖和控制器需要同意存在某些事物。 沒有相應的Controller活動的視圖可能正常工作，但永遠不能使用。 即使Controller沒有做任何事情，靜態頁面中也可能如此：

<?php
class StaticController extends ApplicationController
{

    /**
     * Displays our "about" page.
     */
    public function about ()
    {
        $this->title = 'About Our Organization';
    }
}

然后關聯的View可以只包含靜態文本。 （是的，我之前已經實現了這樣的事情。將靜態視圖傳遞給其他人並說“只需寫上這個。”）很高興。）

如果你看看M，V和C之間的關系作為契約或接口，MVC突然看起來非常“松散耦合”。 警惕獨立PHP文件的誘惑。 一旦你開始包含並需要六個.inc文件，或者將你的應用程序邏輯與你的顯示器（通常是HTML）混合，你可能會更松散地耦合各個頁面，但是在這個過程中弄得一團糟的重要方面。

<?php
/**
 * Display a user's profile
 */
require_once 'db.php';

$id = $db->real_escape_string($_GET['id']);
$user_res = $db->query("SELECT name,age FROM users WHERE id = $id;");
$user = $user_res->fetch_assoc();

include 'header.php';
?>
<h1><?php echo $user['name']; ?>'s Profile</h1>

<p><?php echo $user['name']; ?> is <?php echo $user['age']; ?> years old!</p>
<?php
include 'footer.php';
?>

是的，“profile.php”和“index.php”完全不相關，但代價是什么？

編輯：響應您的編輯：推送MVC。 你說你有“半程序員”，而且我不確定哪一半（你是否有前端人員擅長HTML和CSS而不是服務器端？具有一定編程經驗的作家？）但是MVC框架，你可以只將視圖交給他們，並說“在這部分工作”。

Answer 3

我不得不說我真的沒有看到你的MVC問題，因為你已經在使用模板了。 我將其視為當您嘗試將結構添加到應用程序時自然演變的模式。

當人們第一次開始開發PHP應用程序時，代碼通常是一個大混亂。 表示邏輯與業務邏輯混合，業務邏輯與數據庫邏輯混合在一起。 人們通常采取的下一步是開始使用某種模板方法。 這是否涉及專門的模板語言，如smarty，或者只是將表示標記分離到單獨的文件中並不重要。

在此之后，我們大多數人發現為數據庫訪問邏輯使用專用函數或類是個好主意。 這實際上不必比為每個常用查詢創建專用函數以及將所有這些函數放在公共包含文件中更先進。

這一切對我來說都很自然，我不相信這是非常有爭議的。 但是，在這一點上，你基本上已經在使用MVC方法了。 除此之外的所有東西或多或少是復雜的嘗試，以消除重寫常用代碼的需要。

我知道這可能不是你想聽到的，但我認為你應該重新評估MVC。 有無數的實現，如果確實沒有這些實現適合您的需求，那么您總是可以編寫自己的更基本的實現。

這樣看：由於你已經在使用模板語言，你通常需要首先創建一個普通的PHP文件，然后每次創建一個新頁面時創建一個模板文件。 MVC不必比這更先進，並且在許多情況下它不是。 甚至可能你真正需要做的就是研究更復雜的方法來處理數據訪問並將其添加到當前系統中。

Answer 4

當您需要新頁面時，您必須創建新的模型和控制器操作這一事實我不認為意味着您的M，V和C層緊密耦合。 這只是關注點的分離，有助於解耦系統。

也就是說，很有可能搞砸MVC的意圖（我已經在這樣的應用程序上工作）並使它使組件緊密耦合。 例如，站點可能會將“渲染引擎”直接放在Controller層中。 這顯然會增加更多耦合。 相反，將設計一個好的MVC，以便控制器只知道要使用的視圖的名稱，然后將該名稱傳遞給單獨的渲染引擎。

MVC中糟糕設計的另一個例子是視圖具有硬編碼到其中的URL。 這是路由引擎的工作。 視圖應該只知道需要調用的操作以及操作所需的參數。 然后，路由引擎將提供正確的URL。

Answer 5

Zend框架非常松散耦合，非常好。 看看這個：

http://framework.zend.com

這篇文章也許有用：

http://blog.fedecarg.com/2009/02/22/zend-framework-the-cost-of-flexibility-is-complexity/

Answer 6

你可以試試代碼點火器。 它非常容易學習，並沒有嚴格采用MVC，同時為您的代碼提供了良好的結構。

Answer 7

代碼點火器和Kohana（CI后代）都可以，但也松散的MVC。 我喜歡簡單的PHP框架 。 它不會妨礙你，它提供了重要的東西，而不強迫你的結構或復雜的約定。

Answer 8

啊......好的老MVC論點。

我必須維護一個多方面的PHP應用程序，其中的一些部分是“MVC”風格，但不是全部。 更糟糕的是，不同的部分有不同的做MVC的方式，所有這些都是本土的。 有些頁面只是自己完成。

主要的問題是不存在的框架代碼中的多樣性，但該編碼器顯然不知道如何抽象的API。 IMO，這是MVC框架的最大問題。 我必須使用的幾乎所有代碼都使用“模型”作為放置函數的位置。 維持這是一場噩夢 。

為了使這個可維護，IME你需要一些東西：

• 一個獨特且定義明確的數據訪問層，其API邊界用於檢索和存儲持久存儲，而其他很少。

  我不喜歡使用術語“模型”，因為這是有爭議的。 無論調用該層不應該關心數據的存儲方式，都不應該擔心數據庫句柄之類的問題：這是數據訪問層的全部工作。

• 一個非常輕的調度員，除了調度之外沒有任何魔法。

現在，您可以將其他所有內容放在一個接受請求和參數的地方，可能是從調度程序進行規范化和錯誤檢查，獲取所需的數據（通常作為對象），進行需要進行的更改，保存所需的數據，手需要將數據顯示到視圖中。 代碼通過任務單調乏味兩百線適用於這一步驟。 您不需要將位分配到另一個從其他地方調用的文件中的函數。 您甚至可以將視圖放在此文件的末尾！ 理想主義很樂觀，但實用主義需要一種觀察，因為這是可維護的 。

（好吧，咆哮......）

PHP缺乏強制執行框架意味着最好的框架可以完成PHP的工作：它們不會受到影響。 我工作過的一些最易維護的代碼在頂部有一個require()語句，用數據對象進行所有數據操作（看不到SQL），然后輸出由模板函數包圍的HTML，表單控件為由一致的函數API完成。