iOS架構設計（一）- MVC

語言: CN / TW / HK
時間 2022-06-25 22:15:15
主題:

談起架構，是個很大很大的詞，在開發行業裡似乎又是個很虛很虛的詞，一般情況下，我都是很少去闡述，更多的是應用到自己平時的工作跟解決問題中

人人都可以談架構，畢竟談起來又不需要備案，合適與否，無從可知

架構，最終是要落實到專案上，是否有定式可言

本著敬畏之心，試著展開一些，當然，一篇文章沒辦法談論多巨集大的專案架構跟多優秀的優化設計，只能本著從解決問題的解讀闡述一些觀念，重點還是在於思想

這裡不在於談論對與錯，沒有什麼意義，但是可以相較出更好與更適合

讓我們開始

文中涉及demo下載地址 github

先呈現最初階的程式碼

這裡我們實現了一個tableView，cell操作加減數字

image.png

image.png

image.png

image.png

image.png

這樣的程式碼很好理解，但是，是不用思考的程式碼邏輯，但卻違背了mvc的規範，

  • cell裡可以直接操作model資料的修改

  • 檢視（tableView）在viewcontroller裡，跟控制粘在了一起

改為mvc設計

1.把控制器中的資料來源剝離

單獨構建一個datasource

image.png

image.png

viewController被改成這樣

image.png

datasource 這樣

image.png

cell 中的操作到資料同步邏輯斷了

image.png

image.png

datasource抽離之後，目前檢視是正常的

cell中直接操作model，對model的侵入過深，調整為把操作通過控制器穿出來

操作脫離cell傳出時，需要indexPath依賴

image.png

如果想最小粒度保障操作與資料狀態同步，cell傳遞出操作，響應的換回操作後的資料返回

注意：迴圈引用問題

但如果操作跟資料變化同步不是即時的話，如果存在非同步，可能cell會被銷燬，這個時候需要採用代理的方式，model更新之後，控制器需要協調reloadData

其實，這個時候，一個相對合乎MVC規範的設計就成型了

image.png

貌似還是有些些問題

2.把view從控制器抽離

如果view複雜的話，就需要把view從controller中分離，保障controller職責的清晰

image.png

現在controller裡程式碼意圖更明確了，view就是一個籠統的view，controller並不關注裡面的細枝末節

3.MVC是有缺陷麼？人為缺陷還是設計本身呢？

開發時間久了，經常會聽到這樣一個說法，mvc會隨著專案的複雜度，controller會變得越來越臃腫.........

我並不認同這種說法，按照這樣的邏輯，不管哪種設計，專案複雜了，各種客觀的主觀的原因，一不小心都會使一些程式碼變得臃腫，我倒認為這不是MVC的缺陷

就像最後的view從controller抽離，view最終要的是需要資料來源，控制器就是想辦法把view需要的交付出去，而且還必須明智，就是view只需要拿，具體怎麼拿到的，我就簡單放到view的初始化裡

....看樣子說的又太輕鬆了，你或許心裡可能會說，就是個demo，誰都知道，僅僅這樣三言兩語就說MVC多好，這個demo就是MVC思想如何如何

我不否認，因為我也無法把MVC的原理做到工匠一般通過一篇文章說全說透，只能儘可能盡最大能力把一些問題通過這小小程式碼闡述些，也歡迎有時間有精力的同學不吝指正

這裡我想參考之前的一篇文章，是關於flutter的，其中有關於flutter與原生channel通訊，如何精明的設計block，感興趣的同學可以簡單看下 Flutter引擎原始碼分析(二) - channel原生通訊

4.自然而然引出另一個問題

目前程式碼闡述的還是簡單的demo MVC說明，如果view變得更復雜呢，業務上很遠的view 甚至controller 相互之間會有交集，而且view也會變得複雜得多得多，controller需要協調的控制業務也不單單是demo裡那麼純粹

我覺得那是對MVC有些悲觀了，MVC本身就不是羅塞塔那麼生生堆成一個龐然大物，最後尾大不掉，那是因為MVC 分層分塊的，簡單的說就是 業務邏輯檢視不斷拆分拆分，每個拆分都可以作為一個MVC去設計。 我自認為目前是沒有能力把這塊說的很具體很透徹了，除非拿一個相當大體量的專案來拆解，顯示在這篇文章裡就不現實了

不過另一種設計模式 俗稱的MVP，可能更利於說明上述的問題應該怎麼編排

MVP模式

見（二）儘快更文

文中涉及demo下載地址 github

「」
「」