淺談Unity3D中使用MVC框架模式

淺談unity3d中使用MVC框架模式

MVC框架模式，相信很多人都不會陌生，數據-控制-顯示分離的工作方式或者叫做代碼結構會使軟件（游戲）的結構清晰化，邏輯更明了。但由於MVC框架模式各部件都可以與彼此進行溝通，造成了很多新人在使用MVC的時候消息滿天飛，解耦沒成，耦合度更高了。我建議在使用MVC的時候，制定策略，讓消息單向化，不要雙向或形成網狀。

好了，我們下面討論一下Unity3D是否可以使用MVC，如何使用會比較好?（方法有很多種，這里我只寫我比較認同的一種）

既然我寫了有我比較認同的方式，那么在Unity3D中使用MVC至少我個人持贊成態度，任何東西沒有好與壞，只有適用不適用。

Unity3D本身的MonoBehavior腳本是一個重大突破，達到了組件式開發的目的。但是我依然要說，東西雖好，不能亂搞。我個人認為：組件式開發是好的方式，但組件本身卻是依靠傳統的編程方式建立的，所以除開組件最適用的地方外，強制使用組件進行開發是違和的。MonoBehavior腳本，我們可以將它理解為界面層與界面直接溝通的上層腳本，在他底部的控制、邏輯、數據等有必要用MonoBehavior腳本么？至少我認為是不必要的（為什么要用用不到的東西管理數據和邏輯呢?）。底部的控制、邏輯用什么實現好呢？方式很多，至少MVC框架模式是一個選擇。而在使用MVC時，我個人認為模塊內小規模使用MVC更合理，模塊內的數據、控制、界面關系比較緊密，模塊之間提供合理的接口進行跳轉即可（不排除模塊間消息溝通）。而模塊內使用MVC時，也要遵循消息流向單向化，即：接收方永不發送消息，發送方永不接收消息。有人說不太可能，我給大家提供一個模型供參考：

1.      定義M只提供兩種函數接口：操作、獲取數據；並可以發送更新消息

2.      定義V只接收消息並控制界面顯示、跳轉、效果等

注：界面（暫且稱之為UI）自身處理界面點擊等操作直接調用M層進行處理或內部消化或發送給V進行控制跳轉

3.      定義C實現必要邏輯（非界面自身邏輯）

我們來看以上模型：

a. 用戶點擊->UI響應控制->調用M更改數據->發送更新界面消息->V接收消息->更新界面

b. 用戶點擊->UI響應控制->發送界面跳轉消息->V接收消息->更新界面

c. 用戶點擊->UI響應控制->UI自消化

其實，一般的界面模塊，用以上的模型就足夠了。但有些模塊比較復雜，需要不斷的與數據和界面交互，這時候C才有意義。

 

以上方式，純屬個人比較認可的方式，在實際開發中，每個人都會有自己的觀點存在，但一個項目只能用統一的方式才方便溝通、交接、擴展…