1

按照定義,視圖應該是無邏輯的。當用戶與視圖交互時,它會通知其控制器。當應用程序狀態發生變化時,控制器通知視圖。但是當我們重新渲染一些或全部視圖的時候,我對視圖與其控制器之間的通信的本質感到困惑。控制器和視圖在MVC中應該如何分離?

讓我們假裝我正在做一個雙人牌遊戲。該視圖負責顯示甲板,丟棄堆,玩家手中的牌以及任何其他UI組件。當玩家玩牌時,該視圖需要反映這種變化,而控制者的職責是通知視圖這樣做。以下哪個選項是處理此事件的最佳方法?

  1. 控制器告訴視圖只是爲了重新繪製。該視圖通過控制器可以訪問遊戲狀態的所有參數。它使用這些參數來重新繪製包括甲板,雙方玩家的手等在內的所有東西。

  2. 控制器告訴視圖玩家玩過一張牌。該視圖知道當玩家玩牌時,只有該玩家的手需要重新繪製。與選項1一樣,視圖使用遊戲狀態的參數來確定如何重新繪製玩家的手。

  3. (類似但不同於2)控制器告訴視圖重新繪製該玩家的手並將所需的所有參數傳遞給該玩家。該視圖無法訪問遊戲參數。

  4. 我錯過了其他方法嗎?

選項1似乎是最簡單的兩種寫法,因爲視圖是無狀態的 - 它只是每次都重新繪製所有內容。但出於同樣的原因,這是非常浪費的。當一個玩家玩牌時,我們不需要抽雙手牌。做動畫等事情也很困難,因爲每次我們重新繪製時,我們都會扔掉舊的畫布,並用全新的視圖組件構建新的畫布。

在頻譜的另一端,選項3似乎是從視圖中刪除邏輯的最佳選擇,但它帶有一些問題。首先,我發現編寫起來比較困難,因爲必須將所有正確的消息發送到視圖。如果有遺漏,視圖將無法正確反映應用程序的狀態。其次,當用戶正在恢復正在進行的已保存的遊戲時,似乎還需要全面重新抽獎。

在選項1和2中,視圖「拉」有關遊戲狀態的數據,而這些數據在選項3中被「推送」給它。應該視圖能夠請求這樣的信息,還是這意味着有視圖中的邏輯太多了?

在此先感謝您提供有關此主題的任何信息!

回答

1

MVC不是最適合所有應用程序的。這也取決於可用的框架類型。

通過不考慮平臺/框架我會說HMVC(分層模型 - 視圖 - 控制器)或PAC(演示 - 抽象 - 控制)更適合你,因爲頁面可以被分割成幾個部分(三個視圖:手牌&甲板)。

當談到本地應用程序(GUI)時,MVP似乎比MVC更受歡迎。

Martin Fowler的大約有不同的GUI模式口碑不錯的文章:http://www.martinfowler.com/eaaDev/uiArchs.html

相關問題