模型視圖控制器（MVC）設計模式 - 如何將多個視圖鏈接到多個模型？

Question

示例場景：在屏幕上顯示5個視圖，每按一次，彩虹的顏色就會增加一種顏色。

爲了與MVC設計保持一致，它似乎鼓勵讓一個模型是一個整數或某物的數組，並且每次按下一個視圖時，它都會告訴控制器「嘿，我被按下，只是fyi」和然後讓控制器說「好的，我會在陣列中增加一個相應的位置」，然後讓模型說「我改變了，無論誰在乎」，然後讓視圖說「我在乎，所以我會改變我的現在顏色「。

^這對我來說似乎絕對荒謬。我想我必須有MVC應該完全傾斜的方式，因爲將數據存儲在按鈕本身似乎更有意義。當然，也許按鈕的功能會改變或被重用，所以在按鈕按下它的代表（控制器）時留下該做什麼，但這似乎有點多。

此外，它是否建議存儲與視圖的ID？代表們怎麼知道哪一個被按下？那麼相應的ID應該與模型一起保存？這開始讓我想起像意大利麪一樣的mysql表格...

反正，只是想確保我有那個正確的。

PS-據我所知，沒有其他世俗的力量，在那裏，我的任務使用MVC絕對完美的每一次，但仍想知道什麼是在這種情況下:)

Answer 1

認爲適當的在極限情況投資程序結構可能看起來有點過度。我們會將設計模式應用於「Hello World」程序嗎？我們是否需要添加評論？沒有「最佳實踐」，只有「在這種情況下適當的做法」。

你的設置是一個簡單的模型和平凡關係的簡約系統 - 因此MVC可能是矯枉過正。該應用的特殊功能：

1. 沒有有趣的模型。增加一個值對任何其他值都沒有影響。
2. 有沒有有趣的控制要求。按下一個按鈕不會導致除立即按鈕之外的任何狀態改變。
3. 這聽起來像是一個丟棄程序，沒有未來的維護要求。

現在讓我們考慮一下應用程序可能發生的變化：它是持久的。當你明天運行它時，它會從數據庫中恢復狀態，每次你點擊一個按鈕來保存狀態。

您將如何在最低限度的解決方案中實現？現在有一個知道如何堅持自己的共同模式開始具有價值。我聲稱MVC結構完全避免了這變成意大利麪條。它強加結構，而這個結構是一個維護者會認可的廣泛使用的結構。

我可能對你的問題讀得太多了，但是聽起來有點像你覺得在現有的MVC應用程序中導航很麻煩。這種反應與我曾經看過有人習慣編寫小程序時遇到的結果類似，可能會遇到結構化或OO計劃：他們感到沮喪，因爲沒有單一的流程可以遵循，你不能輕易看到整體結構。我們需要學習的一件事就是能夠採用黑盒方法進行編碼。專注於一個（例如控制器）並暫時將模型和視圖視爲Black_Box。當我從一個大型系統的某個方面轉向另一個方面時，我發現自己幾乎是「換擋」。