軟體開發架構模式淺談：一些思考和實踐記錄

2025-04-22 16:00 阿里技術

一  背景和問題

我個人平時會比較慎用“架構”這個詞
  • 一方面是覺得業界有很多架構大師和架構模式，而我的認知和實踐有限；
  • 另一方面是因為這個詞看著挺高大上、有點務虛，如果不結合實際場景的具體問題來討論，容易陷入“PHP是最好的語言”這樣的辯論賽中。而不同場景中又有各自的問題，程式設計師們透過自己的理解和思考、針對實際場景對一些架構模式進行了擴充套件實踐，以此來解決遇到的問題，也會基於同一個模式延伸出一些派生概念。
兵無常勢，水無常形。所以，我個人的觀點是：以要解決的問題為出發點，去討論我們要採用的架構模式（技術方案）。
另外，由於我們是站在很多巨人肩膀上的，討論時可以站在一些如SOLID等軟體設計/開發原則的基礎上。
寫這篇文章，我也是從解決一些問題的目的出發的：
  1. 最近和團隊同學討論了相關話題，雖然大多數同學在實踐上基本一致，但具體到話術、名詞概念和具體使用的理解和實踐上有些差異（這是很正常的，因為業界對同一個模式的理解和實踐也不同）。我結合一些實際編碼場景做了一番陳述，為了避免後續重複大費口舌，所以打算寫下來，以後有需要直接發文章連結。
  2. 由於我個人的認知和實踐有限，所以也希望能拋（huan）磚（ying）引（lai）玉（pen），讓我學到更多。
  3. 雖然同一個架構模式在不同業務/技術領域的實施會有區別，但同一個團隊內應該保持一致性，因為這樣有助於日常的code review、功能模組的交接backup等活動，尤其是有利於使用統一的單測建設方案來保障我們的產品質量。
    實際問題：我最近在開發商家合併發貨的功能，但由於之前基礎發貨功能的介面和邏輯並不是我開發的，所以我在修改原有程式碼、支援有非常多細節邏輯的合併發貨能力時，就在擔心對原有發（zhong）貨（yao）能力的影響。而這時候，如果有單測的保障，我就可以更放心地進行功能升級改造了 —— 別說更復雜的合併發貨能力了，而這類訴求在複雜的交易場景裡很普遍。
提煉一下我遇到的具體問題：
在由不同開發人員持續迭代、進行功能升級的軟體開發活動中，如何保障具有複雜邏輯的商家經營工具的產品質量。
軟體開發活動是整個流程的核心環節：接收產品和視覺設計需求/變更作為輸入，然後輸出客戶可用的終端產品。
而統一的軟體開發架構模式，則是我們保障軟體開發質量的基礎。（這裡就不具體展開WHY了）
由於討論的是具體面向客戶使用的業務場景，少不了客戶操作互動的檢視層（View），所以我從MVC開始談起。

二  從表現層的MVC談起

雖然我平時比較慎用“架構”這個詞，但我平時喜歡隨手拍一些建築物。因為建築之美，會讓我聯想到軟體的架構也應該有美感，畢竟Software Architecture這個概念也是起源於Architecture。
這時候，架構這個詞就會給我一種接地氣的感覺：有多少塊磚，每塊磚做什麼用、放到哪裡去，這塊磚 和 那塊磚怎麼黏在一起或互相支撐。當然，由於軟體的可移植性、可複用性，從某些角度來講，軟體架構相比建築架構有其更復雜的地方。
MVC誕生至今已經超過40年了（Since 1979），10多年前就得到過很廣泛的討論和實踐，穿越時空到今天肯定有其反脆弱性和內在核心價值。雖然如今乍看起來好像已經過氣、被討論過千百遍了，但仍然有很多程式設計師會有不同理解和看法，或多或少。這是很正常的，上面也提到了部分原因，這裡具體再展開下。

1  MVC在經典三層架構裡的位置

MVC是一種通用架構模式
  • 早期PC時代應用在桌面客戶端，
  • 後來在Web時代變得流行（我以前寫PHP也用過相關MVC框架），
  • 如今在移動網際網路時代也得到廣泛應用。
上面這三個場景的應用，都是面向客戶的，需要互動表現的。
從MVC命名中的View（檢視）也可以看出，MVC模式應用在軟體系統架構裡的表現層。
在業界某知名公司的官方文件裡，也明確把MVC放在Web Presentation Patterns下。
我之所以沒有在上圖中對M-V-C新增箭頭線條，是因為在這一點上，不同程式設計師也有不同理解和實踐。
這是第一個需要明確的點：MVC架構模式在多層系統架構裡的應用範圍。
左側 業務表現層-業務服務層-基礎服務層 是移動端三層架構模式，未涉及到 C/S 互動；右側是Web B/S場景的三層架構模式。
因為有些應用會比較簡單，根本不需要業務服務或基礎服務層，純粹靠一個MVC（或者VC）就能交付出一個Mobile/Web App；
而且在一些業務系統裡，Web前端/桌面客戶端/移動App 也可能會被簡化為 大前端/大終端表現層；
所以可能基於不同資訊，不同程式設計師對此會有不同認知。
但隨著使用者終端應用的重要性和複雜度的提升，已經從簡單應用發展到複雜多團隊協同的平臺型或航母級應用，僅靠一個MVC來完成交付是不合適的。
我們也可以反過來想，程式設計師會把以下程式碼放在客戶端程式碼的哪一層：
  • 對Web引擎的擴充套件邏輯。
  • 通訊協議的結構定義，以及相應的socket連線和通訊程式碼。
  • 一個業務相關且UI無關的平臺開放能力。
  • Crash捕獲、卡頓監控、日誌埋點等功能實現，比如Android在做APM相關事情時會採用AOP方式，利用ASM、AspectJ等方案來做位元組碼插樁。
  • ……

2  業界基於MVC模式的不同實踐

前面提到不同程式設計師對MVC模式的理解和實踐存在差異
業界大廠亦然，以下會結合業界一些知名且有影響力的公司在MVC模式上的實踐，做進一步的展開討論。

知名公司A

知名公司A在指導開發者使用MVC時，推薦下圖方式：
可以看出在他們的實踐上：
  1. Controller可以引用View和Model。
  2. View可以引用Model。
  1. 這裡的Model傾向於是Passive。
同時，他們建議：
  • 在強型別檢視場景，控制器從模型建立並填充ViewModel例項，該ViewModel 例項包含要在該檢視上顯示的資料。
  • 當控制器由於責任過多而變得過於複雜時，也就是業界戲稱的“MVC means Massive View Controller”，需要將業務邏輯從控制器移出並推入域模型中。

知名公司B

說到Massive View Controller，知名公司B在移動網際網路方興未艾的時候，推薦下圖所示的MVC實踐方案：
上圖呈現出：
  1. Controller引用View和Model。
  2. Model透過一些松耦合方式來觸達Controller，如廣播通知、callback等，驅動Controller做出響應。
  3. View透過代理模式等方案弱依賴Controller，由Controller對各種使用者操作、UI渲染訴求做出響應。
  4. 而View和Model之間是隔離的，Model變化後對View的更新操作全部由Controller負責。
不過相應的官方文件已經被宣告是過期文件了，並備註不一定是目前的最佳實踐。
是的，隨著移動網際網路蓬勃發展，十年前的“最佳實踐”被一路多種挑戰 —— 在採用這種方案的開發領域中，如何重構Massive View Controller為Lighter View Controller已經成為了一個專題。

對比和思考

A和B的異同點
  • 相同點：Model包含 所需的資料結構封裝，以及相應資料操作的方法定義。即Data + 本地或遠端的CURD。
  • 差異點：在知名公司A給的圖中，View可以引用Model，而在知名公司B給的圖中則不行。
一些問題和思考
  • View有箭頭指向Model，這裡的引用關係是指什麼？是View持有Model.Data資料物件，還是View呼叫Model.CURD方法。
  • Controller的本意是Controing Logic，那除了ViewController外，是否還可以有其它的XxController，比如DataSourceController、NotificationController？
  • 從命名上看，既然ViewController 既有View 又有Controller，那為什麼把它放在 C裡面，而不放在V裡面呢？比如當我們在iOS/Android開發中引入MVVM模式後，ViewController或Activity屬於M-VM-V的哪部分呢，程式碼放在哪個目錄下呢？
  • 我有類名使用ViewModel字尾就代表我使用MVVM模式了嗎？

Martin Fowler

作為
  1. 《重構 : 改善既有程式碼的設計》、《企業應用架構模式》等著作的作者；
  2. 敏捷軟體開發宣言創作者之一；
  3. MVVM模式誕生時參考引用的技術專家。
Martin Fowler給的MVC模式圖如下：
和上面知名公司A和B的圖，又不一樣了，不過他這裡也是認為View可以引用Model的。

MVC和DDD

Martin Fowler和《領域驅動設計》作者Eric Evans也討論過MVC中Model的設計理念：
  • 貧血模型：將Model分為簡（pin）單（xue）的Model資料物件，和處理操作資料物件的Service/Manager/BizLogic等。
    • 示例：為aPerson修改name，則由 CitizenService.changeNameOfPerson( aPerson ) 這種方式來實現。
  • 充血模型：將對應領域的處理邏輯放到領域模型中，使得這個領域模型更飽（chong）滿（xue）。
    • 示例：aPerson要刷牙，則由 aPerson.brushTeeth() 來實現。
    • 補充：充血模型更有面向物件程式設計的味道，尤其是搭配交易領域等業務場景，更有體感。不過稍微細想一下，可能就會發現DDD對設計的要求會更高，從而對研發週期和質量保障提出了新的要求，並且可能引起對現有系統的大規模重構。（盒馬的DDD實踐）
也就是說，大到MVC各個模組的依賴引用關係，細到Model中的程式碼設計方式，業界都有不同的理念和實踐。
Java Web開發領域也對Model的設計產生過非常激烈的討論。

小結

先拋開具體模組的程式碼設計方案，基於以上幾種業界大廠或專家的描述，我小結了以下這張圖並標註了待解問題：
問題一：如何解決MVC中Controller的膨脹臃腫問題？
要回答如何解決，需要先思考為什麼膨脹。
問題二：View能否引用Model？
  • 要回答能否引用，需要先定義引用關係是什麼。
    • 是持有物件，還是呼叫CURD介面操作物件。
    • 又或者這兩者沒有必要區分，因為持有的物件本身就可能帶CURD介面。
  • 參考上面相關資料，目前業界有的支援、有的反對。
問題三：存在View -> Model，那麼是否可以反過來存在 Model -> View？
和問題二在描述上相反但又有關聯，如果對問題再進一步提問的話：
  • 使用 -> 引用關係，是為了解決什麼問題？
  • 使用 -> 引用關係，會產生什麼問題？
如同文章開頭所說，以上問題需要結合具體場景來展開（見 實際案例結合），儘量從務虛到務實。

3  Redux-like Architecture and Framework

隨著前後端分離得更徹底，終端裝置效能和使用者體驗重要性的提升，前端領域也得到了蓬勃發展，開發方式也有了比較大的變化，MVC-like方式不再是主流：
  • UI開發方面從早期的命令式到現在的宣告式。
  • 整體應用和業務邏輯實現方面，從早期的OOP寫法，轉向基於FP的響應式程式設計。比如Redux的資料流、React的Hook特性等。
  • 各種框架蓬勃發展，一些概念和模式的提出、實踐應用方面，我個人認為是領先並影響客戶端的。
    • 其中Redux是一個經典案例，並且我覺得Redux官方也挺開放包容的，比如Dan Abramov寫的《You Might Not Need Redux》。
和MVC延伸派生出的MVC Family一樣，Redux提出或重新帶火了資料流、狀態管理等概念，開始影響其它平臺領域，並誕生了一些框架。
比如ReSwift、swift-composable-architecture，以及SwiftUI裡的State and Data Flow。
雖然我也寫過點React，但並沒有怎麼實踐過Redux。
不過這些變化和影響，是我們在解決問題的過程中需要結合考慮的。

三  實際案例結合

1  常見的資料結構定義和使用

程式 = 資料結構 + 演算法。
—— Nicklaus Wirth，Pascal之父，圖靈獎獲得者
這句話乍看起來可能會有點面向過程設計的感覺，但OOP中的物件其實也是由資料+方法組成，而FP則更不用說了。
在編碼開發活動中，會存在以上3種資料結構定義和使用方式：
  1. 原生資料結構，比如list/array、map/dictionary、tuple等。
  2. 類似MyContact的資料結構定義，由服務端返回的資料進行轉化，並可能根據業務邏輯按需加上一些標誌位給Controller消費。
  3. 類似ContactViewModel這樣的純粹為檢視View服務的資料結構定義。
補充：
（1）MyContact 和 ContactViewModel 只是特意區分的命名，實際上 MyContact 也可以是純粹為檢視View服務的資料結構定義。
（2）但是，合適的命名有助於幫助我們思考和編碼，從表達上呈現出我們的傾向和重點。
"There are only two hard things in Computer Science: cache invalidation and naming things."
—— Phil Karlton

2  常見的多複雜卡片的列表場景

這個場景可以部分回答問題一：為什麼Controller會膨脹，以及如何解決。
其它部分答案則落在複雜頁面場景的多delegate、target-action、notification-observer等檢視互動響應的處理邏輯上。
我認為，之前反對View引用Model，就是導致MVC變成Massive View-Controller的一個原因。
另一個原因我認為是工具鏈只提供了ViewController這樣的Controller模板，隱式教導開發者都在這裡寫程式碼。
這也可能是因為十幾年前移動網際網路還沒發展起來，移動App的複雜度低，所以提供了在當時簡單夠用的方案。
當只能由Controller 持有-> Model的時候，那麼在多複雜卡片的列表場景中，必須由Controller來更新每個View的屬性/狀態。
  1. MyViewController需要為ContactCell更新它的各種相關屬性，類似的還有AddressCell、PackageCell等。
  2. MyViewController在更新AddressCell展示前，可能還需要先為它計算出合適的富文字展示內容。
  3. MyViewController需要響應不同Cell的點選互動行為，包含但不限於按鈕點選、輸入框變化、富文字跳轉、鍵盤起落等。
  4. MyViewController需要響應CollectionView/TableView的DataSource/Delegate各種方法實現。
  5. MyViewController需要響應Model層的變更通知，或者是另外一個ViewController拋過來的廣播通知。
  6. ……
然後MyViewController就爆炸了。
針對這種場景，我的解法是：
  1. 透過讓View->Model，基於工廠模式，把元件化Cell基於資料更新的佈局邏輯交給View負責，如contactCell.configUIWithModel( contactModel )。這樣有點類似上面DDD提到的充血Model，具備高內聚的特點，帶來好處：
    1. 和減輕控制器負擔、推入域模型類似，透過把資料驅動佈局的程式碼推入元件域內，減輕了MyViewController的負擔。
    2. 利於做這部分元件化Cell的UI測試。
    3. 利於這些元件化檢視複用到其它場景，比如交易管理場景的訂單卡片可以複用到搜尋場景中，不用在SeachViewController裡複製貼上一大堆程式碼，只需要從Model取一個數據物件丟給元件化Cell即可。
  1. 基於ViewController，拆分出不同職責的擴充套件，比如MyViewController+Delegate專門複雜響應代理事件處理。
  2. 定義出其它型別的Controller，比如MyDataSourceController，專門為TableView提供資料來源，可以類比參考Android中ListView的Adapter+ViewHolder。
工廠模式下，產品的刷漆、烘乾、印花等操作會在內部完成，不會丟一個模型讓客戶去自己貼logo。MVC的每一部分都可以用不同的設計模式來組合實施，實現解耦或動態靈活的目標。
對應下圖： 

到這裡已經回答了前面的問題一和問題二。

更多解法可以參考上面提到的相關建議，比如lighter view controllers
這裡採用了 VIew -> Model 的方案，用來參與解決Massive View-Controller的問題，並且讓View更容易複用和做UI測試，帶來了好處。
可以結合前面提到的
“當控制器由於責任過多而變得過於複雜時，需要將業務邏輯從控制器移出並推入域模型中。”
再進一步討論下。
我的理解和舉例：
  1. 存在一個輸入框，讓使用者提交物流單號。
  2. 使用者在輸入過程或者完成輸入後，由View透過delegate模式路由給Controller做校驗，而Controller可能還要進一步依賴Model去做更完整的校驗（如網路請求到服務端，因為物流單號的規則很多而且可能動態更新）。
  3. 當Controller責任過多、程式碼膨脹、過於複雜時，就將物流單號這塊業務邏輯推入 物流（單號）域模型中，即由View直接透過delegate模式交給 LogisticsModel來做校驗。
  4. 也是 View -> Model 。
不一定對，拋（huan）磚（ying）引（lai）玉（pen）。
那麼，存在VIew -> Model，有什麼壞處嗎？

3  一個Kotlin跨平臺場景案例

這裡不具體展開講Kotlin及其跨平臺相關內容，只是描述從MVC模式做跨平臺遷移時遇到的問題。
這裡的ViewController/Activity放在哪裡，也和上面的一個問題相呼應。
雖然D-KMP主張透過全新構建工程寫程式碼的方式來實踐，但從實際情況出發，絕大多數現有系統都會是以單點嘗試、漸進式的方式來落地，或發展、或回撤。
那麼，如上圖所示：
  1. 如果在既有MVC程式碼結構中，View -> Model，在這種漸進式遷移場景下，就需要修改View來適配新的ViewModel。
  2. 如果 View 不引用 Model，則是由 Controller來做膠水層設定更新檢視（命令式UI）。
  3. 後者的好處是，保持View的獨立性，只需要修改這個業務場景對應的單個Controller即可。因為View具有可複用性，可能在另外還沒準備遷移/改變的模組裡也有使用。
所以，此處不建議 View -> Model。那麼，誰對呢？

4  誰對誰錯的務虛討論

當有程式設計師要推薦使用其它架構模式的時候，通常開頭的一句話就是先說MVC模式的問題。
比如ReSwift在寫 Why ReSwift? 時，開頭第一句話就是：Model-View-Controller (MVC) is not a holistic application architecture.
我個人認為
  • 架構是一個名詞（n.）+動詞（v.）。
    • 架構（n. & v.）是為了幫助 開發者在交流時有一致的理解、在業務需要時能夠便於擴充套件、在出問題時能夠快速定位等等（對抗熵增）。具體還是看採用這個架構的得失，要解決什麼問題或帶來什麼好處，然後帶來什麼成本或付出什麼代價。
    • 架構（v.）透過分配每部分程式碼的職責併為他們取名（好比iOS/Android開發工程師這樣的崗位名稱，讓別人一看就知道是做什麼的），然後幾個名字加在一起 形成了架構模式這個抽象概念。
    • 從具體到抽象，然後再由這個抽象概念去指導程式設計師實踐寫程式碼，促進了架構的傳播，比如MVC、MVP、MVVM、MVVM-C、MVI、MV-Whatever，VIPER，Redux and More……
  • 有時候並不一定是架構模式的錯，還有可能是平臺/框架在讓架構模式自傳播時採用的具體方案出了點問題，又或者是開發者自己寫程式碼的問題。
  • 有時候架構模式之間也不是互斥的，也可以在不同場景下互補。比如在MVC裡，每個業務表現模組不一定要有三個元素齊聚，甚至也可以 VC-M-VC 共用一個M（可參考斯坦福iOS開發課程內容）。
有一個實際的業務場景是這麼實踐的：
MVC和MVVM在一個業務場景裡相結合。
這裡提到了MVVM，前面的Kotlin跨平臺圖，除了涉及到 View -> Model 的引用關係是否應該存在的討論，也涉及到了Declarative-UI和MVVM架構模式等概念，再順便展開下。

1）MVVM 和 MVW

MVC、MVP 和 Declarative-UI 這三個名詞概念都有幾十年歷史了，其中宣告式UI在近十年又開始火了起來；而MVVM則有十幾年歷史。
官方對MVVM有這麼一些描述：
  • V和VM是一對多的關係，即View 1:n ViewModel。相比於 MVC裡 Controller 1:n View，顯然MVC的C更容易膨脹，所以上面也提到了使用多Controller方案。
  • V引用VM，VM操作M，而VM不需要引用V（和MVP不同）。VM作為V的上下文，包含V所需用來展示的資料，響應V被使用者觸發的事件。
  • V對M無感知，反過來 M 對 V和VM 也無感知。整體是鬆散解耦的模式。
  • 當VM的屬性值發生變化時，透過資料繫結方式傳達給V。這就需要有機制支撐，有對應的機制MVC也能做資料繫結。
基於上述描述我畫了下圖：
總體來說，MVVM是基於事件驅動的、以資料繫結機制為支撐的鬆散解耦架構模式。
  • 它的前提是有系統/平臺/框架的機制支撐，不然實現成本和複雜度有點大。
  • 相比MVC，它的優勢是檢視控制邏輯不太會膨脹，程式碼單元更容易被測試，在可讀性、可維護性上更好。
  • 它可能帶來的成本/問題是入門上手較難，簡單場景下使用容易過度設計，複雜場景下出問題除錯比較麻煩。
考慮到ViewController在該場景的薄膠水特質，以及也參與檢視展示和使用者響應，所以我把它放在V裡。
由於業界有太多MV-開頭的模式名詞了，所以Angular官方直接聲明瞭一個MVW：
I hereby declare AngularJS to be MVW framework – Model-View-Whatever. Where Whatever stands for "whatever works for you".
這種宣告有個好處，就是免去了誰對誰錯/誰好誰壞的爭執，而重點關注於誰適合。

5  誰對誰錯的務實案例：VIPER和分層演變

關於誰對誰錯/誰好誰壞，可以再來看一個案例。

VIPER架構模式的應用

VIPER概念由View、Interactor、Presenter、Entity、Router幾個元素組成，大致如下：
我之前寫過MVC、MVP、MVVM、VIPER等架構模式下的程式碼，完全實現或不完全實現。
有一次，我在某個業務表現模組裡應用VIPER，然後定義了一個XxxNetworkInteractor類，用來負責做網路請求。
VIPER架構模式的演變
後來隨著業務場景的變化，一個業務模組可能需要對接多套閘道器服務，XxxNetworkInteractor就要做抽象隔離，消除業務邏輯對多套閘道器請求的感知，並且應用到其它業務模組。這就有點像 VPER – I – VPER 模式 —— 多個業務模組對 Interactor 進行了複用。
進化
  • 隨著對接閘道器數的增加、閘道器能力的增強，XxxNetworkInteractor也配套建設了更多能力。
  • 隨著使用XxxNetworkInteractor的模組越來越多，不同業務的一些通用訴求和處理邏輯也隨之增加。
  • 隨著XxxNetworkInteractor的功能越來越強大，程式碼越來越多，逐漸需要抽離出一個單獨模組，不管是從提高編譯速度，還是從封裝暴露等角度。
於是，XxxNetworkSDK.framework誕生了。
退化
再後來，隨著技術和業務的變化，底層閘道器服務ATop成為了領域範圍內的事實標準，之前遇到的問題也消失了，而XxxNetworkSDK又帶來一些成本，比如要配套ATop的能力升級進行迭代維護。
此時，XxxNetworkSDK可以退出歷史舞臺了，讓業務模組直接面向ATop程式設計，這樣既降低了維護成本，又帶來了一定的包大小收益。
以後，假如有另外一個領域範圍的業務場景（採用了XTop），要複用最上層的業務模組，由於在另外一個領域範圍，業務模組要從 呼叫ATop 改為呼叫XTop。
那麼，接手或負責遷移複用的開發者，會不會在想：為什麼這些業務模組直接呼叫ATop，而沒有使用一個XxxNetworkInteractor來做分層隔離呢？讓業務不要感知具體的資料庫或網路服務實現。
  • 如果有，他只要做一件事情：讓XxxNetworkInteractor對接XTop即可。
  • 如果沒有，他需要去替換修改每個業務模組的呼叫程式碼、返回值處理等等。

四  寫在最後，回到問題

不管是務虛的討論，還是務實的案例，或者是Angular的“whatever works for you”的觀點，結論是沒有誰對誰錯、誰好誰壞，只有實際場景下要解決的核心問題。
兵無常勢，水無常形。那麼，回到想要解決的問題：
在由不同開發人員持續迭代、進行功能升級的軟體開發活動中，如何保障具有複雜邏輯的商家經營工具的產品質量。
我的想法是以可測性作為手段，來保障功能升級改造或程式碼重構後，可在合理時間範圍內得到充分迴歸驗收，保障相關元件、模組或整體產品的質量。
具體的方案實施上，因為是以可測性為重要關注點，再結合目前的技術方向，我會傾向於採用MVVM。
  • MVVM的架構模式在理解和認知上比較成熟（應該是移動端開發領域TOP2流行的），便於實施和傳播，並透過模式的名稱來體現要強調的關注點：可測性。
  • MVVM可以更好地結合SwiftUI+Combine、Kotlin跨平臺等技術方向。
  • MVVM完全版的上手門檻和簡單場景的過度設計問題，可以透過採用不完全版MVVM來解決。
    • 不完全版的MVVM可以cover適用於簡單場景的MVC，近似於 超集-子集 關係。
    • 雖然也可以透過多Controller的方式來解決MVC膨脹問題，但MVC的命名在實踐中就容易讓程式設計師弱化掉可測性這個關注點（也可能是我個人理解和實踐不夠正確）。
  • 複雜場景的除錯問題、更多可測性的實踐，需要再摸索下，也希望得到相關分享和指點。
阿里雲｜MongoDB中國區域遊戲行業私享會重磅來襲！
誠邀您與Mongo DB、阿里雲資料庫專家團隊， 以及遊戲行業同行共同探討如何使用Mongo DB幫您打造全球化高效、易用、穩定的資料庫架構，為您詳細解MongoDB5.0新特性在遊戲行業的最佳實踐。點選閱讀原文檢視詳情！


相關文章