MVC：爲什麼模型，視圖和控制器的分離？

Question

除了它的「哲學」方面，讓我的控制器也成爲我的模型是不是一個好主意？

它似乎節省了一些編程時間。我不必在控制器和模型之間創建邏輯，因爲它們是一樣的。我可以直接與視圖進行交互。

什麼是分離的M和C的點？模塊化 - 也就是說，將一個模型和控制器交換爲另一個的能力 - 將它們分開的唯一原因？在我看來，「交換」模塊的出現比（例如）必須更新模型和控制器要少得多，因爲模型中的某些內容正在發生變化。

---

這似乎很奇怪，一個簡單的計算器，根據MVC概念，應該有兩個控制器和用於其設置的視圖（如默認設置，或東西）。我知道這是一個簡單的例子，但它似乎適用於所有情況（除了可能的框架）。

Answer 1

主要原因是代碼的可重用性。如果你只在你的職業生涯中寫一個程序，那麼也許沒關係。如果你打算從事這件事，那麼擁有可重複使用的作品是有價值的。精心設計的模型，控制器和視圖類很容易放入其他程序中。我一直這樣做。

考慮UITableViewController，這是一個控制器。現在想象一下，如果它是專門用於處理音樂曲目（模型）的，並且當您想要處理其他內容時您需要創建一個完全不同的表管理類。避免這種噩夢是MVC在可可中大量使用的原因。

還有其他的方法來分解事情。一些語言嚴重分類而不是委託。但在Cocoa中，分割程序的主要手段是MVC，並且它工作得很好。

編輯：只是從開發商業應用程序的世界的一些原因。

• MVC中的內存處理要容易得多。您可以抓住您的模型對象，並在屏幕上扔掉視圖對象（以及許多控制器對象）。

• 序列化未包含控制器和視圖的模型對象更容易，而且以多種方式顯示相同的數據更容易。即使在「簡單」文本編輯器中，您也可能希望能夠進行分屏操作，或者有多個窗口顯示相同的文檔。在MVC中這很容易。

如果您現在或將來不需要靈活性，則不需要太多架構。但大多數真實的項目並不那麼簡單。 MVC源於施樂在編寫大型程序方面的經驗，以及將所有內容放在一起時遇到的困難。

---

編輯2：我看着你剛纔的編輯：「這似乎很奇怪，一個簡單的計算器，根據MVC概念，應該有兩個控制器和用於其設置的視圖（如默認設置，或者其他）。「

這正是MVC的原因。爲了專門爲Calculator應用程序保存用戶設置，必須重新編碼所有必需的東西，這似乎很瘋狂。你需要一個通用的「請保存這些用戶設置」，這是完全獨立於用戶界面，你可以重複使用。在OS X上，它被稱爲NSUserDefaults，而Calculator應用程序正是以這種方式存儲其配置。

Answer 2

如果它適合你，那麼它的工作原理。期。模型，視圖和控制器的分離原因圍繞着這樣的想法：企業應用程序的大多數開發都是由開發團隊完成的。

試想10個開發人員嘗試將控制器上工作。但他們想要做的只是在模型中添加一些東西。現在你的控制器壞了？他們做了什麼？

Answer 3

模型被控制器之間可重複使用通常單獨的部件。如果你是絕對確定你不會在多個控制器中重新使用模型，我真的沒有看到混合這些問題的問題。

我想有人會說，爲什麼甚至使用MVC的設計，如果你是在偏離計劃。也許有一種更適合你的情況的模式。你能否給我們舉一個你在控制器是模型的地方做過的事情的例子？這將有助於我們理解你正在努力做得更好。

Answer 4

MVC是發展界熟知的標準模式，並有很好的理由。分離確實使得易於閱讀，易於排除故障，易於查找和易於測試的組件，每個組件都有其自己的責任區。

你必須使用它嗎？當然不是。但保持零件分離通常被認爲是一個好主意。

Answer 5

控制器知道如何將特定視圖鏈接到您的模型。除了改進文檔和可維護性之外，模型和控制器的分離具有允許多視圖顯示來自模型的相同信息而不增加任何複雜性的直接益處。

這不僅適用於同一個應用程序中的多個視圖，還適用於跨應用程序的多個版本的多個視圖變體。你的模型是絕緣的，邏輯清潔。

在我看來，結合模型和控制器是一種經典的虛假經濟。它可能覺得它可以節省幾分鐘的時間，但隨着應用程序的發展和增長，它的成本會非常高。

Answer 6

MVC完全是關於管理（數據，表示和業務邏輯的分離）。所以就是這樣：如果你經營一家小公司，擁有一個MS大小的管理將是一個真正的拖累。但如果你是一個大公司，沒有大的中層管理是不可能的。

老實說，在我的大部分大學課程作業中，我將模型和控制器結合起來，因爲我沒有看到分離的必要性。但是在大項目上工作？如果你不嘗試分離，這個缺陷會非常明顯。只要做你覺得正確的事。

Answer 7

該模型不依賴於視圖或控制器。這是分離的關鍵好處之一。這種分離允許模型獨立於視覺呈現而被構建和測試。