爲什麼MVC如此受歡迎？

我原本打算讓這個問題更長一些，但我覺得我做得越短越好，你會明白我的意思。爲什麼MVC如此受歡迎？

MVC架構模式有3個依賴關係。該視圖取決於模型。控制器取決於視圖和模型。該模型是獨立的。
各層架構模式定義N - 1間的依賴關係，其中，N是層的數量。

給定三層：模型，視圖和控制器，只有2個依賴關係，而傳統的MVC只有3個。該結構是這樣的：

View ---> Controller ---> Model

[查看取決於控制器，控制器取決於型號]

在我看來，這種風格完成同樣的目標和產生更鬆散的耦合。爲什麼這種風格不常見？它是否真的實現了相同的目標？

編輯：沒有ASP.NET MVC，只是格局。

關於griegs的帖子：

至於嘲諷，圖層仍然允許您使用命令處理器模式來模擬按鈕點擊，以及其他一系列活動。
用戶界面的變化仍然很容易，甚至可能更容易。在MVC中，控制器和視圖傾向於一起齧合。圖層會創建嚴格的分隔。兩個圖層都是黑色框，可以在實現中自由變化。
控制器對視圖有0依賴性。視圖可以被寫入，並且時間仍然可以通過鬆耦合來保存。

來源

2010-09-02 Mike

我還沒有得到回到這個在很長一段時間，主要是因爲我還在想。我不滿意我收到的答案，他們沒有真正回答我的問題。

最近，一位教授指導我走向正確的方向。實質上，他告訴我：分開模型，視圖和控制器的層是 MVC。在vanilla MVC體系結構模式中，View和Model之間的依賴關係通常不被使用，而且最終會有效地使用Layers。這個想法是一樣的，命名只是很差。

來源

2010-11-03 12:16:07 Mike

因爲你從更改更容易控制分離的接口。

還要考慮場景，你需要獲得一個項目開始，但作品將不準備數週或數月。您是等待還是編寫頁面所需的所有代碼，然後將視圖連接至控制器。

至少，這就是我們所做的，我們保存幾個月。

而且它使用戶界面的變化更容易應對，因爲沒有在做了什麼我們的aspx頁面的任何代碼。

我們的測試結果也更好，因爲我們可以嘲笑任何東西，包括按鈕點擊等

如果你正在談論的asp.net MVC架構，有在ASPX文件並沒有視圖狀態無碼等等。

來源

2010-09-02 01:14:04 griegs

你假設他指的是ASP.NET MVC，而不是MVC模式，這是他問到的。 – 2010-09-02 01:15:36

+10

不，我不是。只有在我最後一次轉變時，我纔會這樣做，我甚至會說「如果你正在談論......」 – griegs 2010-09-02 01:19:35

視圖和控制器，並且固有地與MVC耦合。由於兩者都被模擬爲黑匣子，每個都可以被嘲弄和/或修改。我不覺得你指出了區別，非常相似。 – Mike 2010-09-02 01:20:27

在正確的MVC中，控制器不依賴於視圖afaik。或者，也許我沒有正確理解它。

該模型定義了數據。

該視圖定義了輸出的樣子。

而控制器是從模型理解的語法轉換爲視圖理解的語法。

所以基本上控制器是獨立的。該視圖是獨立的。模型是獨立的。

是嗎？沒有？

來源

2010-09-02 01:14:46

這是我的印象： http://prajwal-tuladhar.net.np/wp-content/uploads/2008/10/mvc-architecture.png – Mike 2010-09-02 01:18:02

每一個（或多或少）都是獨立的，但你的角色是控制器錯誤。控制器基本上接受用戶輸入，並相應地修改模型或視圖（儘管有些實現繞過控制器僅執行修改視圖的操作）。 – 2010-09-02 01:39:27

-1

在我看來，你最好在你的程序中嘗試一下，你可以在rails或codeigniter（用於php）上使用ruby，這些很棒的框架可能會有助於你理解MVC。

來源

2010-09-02 01:35:53 keepyouliking

CakePHP也是很好的PHP MVC框架。有了Perl，你可以嘗試Catalyst。 .NET和Java，好吧，我猜每個人都已經知道了大名:) – 2010-09-02 01:56:35

我會大膽的，並試圖解釋爲什麼你的方法沒有得到滿足。

MVC模式基本上要求視圖和模型層在API上達成一致。由於一個服務於另一個，並且代碼內部沒有依賴項，所以它只需要在視圖層採用特定的結構，並在模型層上調用匹配的API。

你會注意到，在視圖和模型之間商定一個API並不是真的這麼重要，它必須發生。而你得到的是後端前端開發之間的良好分離。

在您提出的解決方案中，控制器端需要大量開發。控制器將需要了解視圖中的所有元素，並將它們映射到模型圖層所需的特定調用。由於控制器是一個單獨的接入點，可以將許多視圖連接到多個模型，因此可能會很快失控並最終成爲一個難以理解的控制器模塊。

看一些Struts2的例子來看看我的意思...

來源

2010-09-02 01:41:18 Asaf

控制器層需要絕對不依賴於視圖層。事實上，這種模式限制了它。此外，MVC聲明每個視圖有一個控制器，多個視圖和一個模型。所以這也被照顧了。 – Mike 2010-09-02 01:45:24

因此，如果我在網頁上提交表單（視圖）如何應用適當的業務邏輯（模型）？如果您的視圖和型號是真正獨立的，則控制器必須具有以下定義：（input1 - > call methods 1,2,3）（input2 - > call methods 2,3,5） ... 我相信這是模式的大多數實現都試圖避免 – Asaf 2010-09-02 01:51:00

如果方法1,2,3是模型方法，具有諷刺意味的是，我試圖實現這一點。這很有道理。聞起來甚至很容易清理Command模式。 – Mike 2010-09-02 01:55:53

我想我理解你的觀點：

是的，你可以查看僅只有將控制器取決於控制器將Model對象轉換（使用PHP作爲示例）到非模型對象（如簡單數組）。我們已經知道，如果實際上不需要解耦，那麼執行這種轉換可能比它的價值更努力。如果視圖使用模型對象，則它具有此依賴性。但是，通過使View僅依賴Controller的所需輸入（可以是Model對象），可以緩解這一點。

Symfony PHP框架在Model和View之間推廣了這種Skinny控制器混洗的風格。您仍然可以直接調用Model層以檢索View層中的對象，但強烈建議您避免出現耦合問題。在View中，如果需要查詢模型，您可以調用include_component（），實際上它返回到Controller。

來源

2010-09-02 03:18:23

是的，你已經知道了，@Rob Olmos。所以有時會使用它。我只是感到驚訝，它沒有被更多地使用，特別是因爲有一段時間沒有人真正理解我在說什麼。 – Mike 2010-09-02 11:44:55

即使在我的組織中，我們仍然在爭論是否強制Controller僅將非模型變量傳遞給視圖..尚未做出決定，但我們正在試驗它的可行性...... – 2010-09-03 03:12:40

爲微軟平臺上的新型或企業Web開發選擇演示模式是一項艱鉅的任務，我認爲只有三種;查看模型，模型 - 視圖 - 演示者（MVP）或ASP.NET MVC（Model2派生）。

你可以在這裏閱讀完整的文章ASP.NET MVC Patterns

來源

2010-09-02 08:26:02 MetalLemon

我想添加一些更多的東西。首先，爲了我的觀點，我們使用該模型作爲容器，用於我們想要傳遞並顯示在視圖上的信息。

在視圖：一般操作方法到控制器與返回視圖（「的viewName」，型號）。該圖本身probabily將改變其layour靠在模型結束

如果（model.something ==真）{

％>

somethign顯示

<％

}

在這一點上，模型的定義很難找到。

我可以說（特別是在企業conext）的兩個「模式」

一個是域模型/實體模型或你想怎麼稱呼它包裹從下層傳來的數據（數據庫，等等）以及包含我們想要顯示的信息的視圖模型加上我們需要隱藏/顯示接口的一部分的任何其他信息

控制器編排視圖並且與視圖獨立，但與視圖獨立型號：

進控制器

pulic的ActionResult指數（）{

....

如果（model.BoolProperty ==真）{

回報（「的firstView）;

}

別的

{

返回（「secondView」）;

}

我希望這是有道理的

來源

2010-11-03 12:06:47

爲什麼MVC如此受歡迎？

回答

相關問題