在App 文件劃分的時候，實際上已經(jīng)考慮好我們的基本架構(gòu)是怎樣的逸尖，整體來說是 MVC 或者說MVC 的變種刁标，整體來說還是根據(jù)項目的的大小和具體需求來定。而我個人最近也在想這塊的問題险污，特此一步一步理一下。
MVC （一）
- Controller ： 干了超多事情, 各種事件
- View： 呈現(xiàn)視圖事件
- Model：數(shù)據(jù)的Model 化
- Other： 管理類以及一些工具
此時如果業(yè)務(wù)一下子復(fù)雜之后富岳，Controller 里面承擔的工具確實會太多了蛔糯，會太臃腫啦，至少維護起來是尷尬的窖式，所以此處相對來說適用于小型項目蚁飒，項目大一點就要將其 Controller 里的部分抽取出來。
MVC （二）
此處相對于 MVC（一） 來說萝喘，就是將 請求事件單獨再抽離出來淮逻，讓 Contoller 只要通過一個回調(diào)的形式請求數(shù)據(jù)，然后達到 輕 Controller 的目的阁簸，我認為相對來說這又進步的爬早。
MVC （三）
- Controller ： 各種邏輯事件和跳轉(zhuǎn)
- View： 需要呈現(xiàn)的視圖
- ViewModel: 數(shù)據(jù)的請求
- Api: 網(wǎng)絡(luò)請求的配置
- Model：數(shù)據(jù)的Model 化
- Other： 管理類以及一些工具
這是我們之前嘗試過的一種另類的 MVVM 變種類型，就是 ViewModel 不僅充當請求的處理還有部分代理的實現(xiàn)：
- 類似 UITableView的代理强窖，方便之處就是類似 UITableView 中很多代理事件直接在其中實現(xiàn)了凸椿，無需再返回到ViewController 中去處理。
- 像 UITableView 中的 Cell 和 HeaderView 直接在 ViewModel 中處理
- 以及類似空頁面的代理也可以直接放在 ViewModel 中翅溺，這樣就讓 ViewModel 在有些時候成為 列表頁面的擴展類的感覺脑漫，但確實很方便。
然而最大的問題就是咙崎，可能ViewModel 和 ViewController 中里面實現(xiàn)是事件類型不統(tǒng)一优幸。
例如：
- 跳轉(zhuǎn)事件即出現(xiàn)在 ViewModel 中，也可能出現(xiàn)在 Controller 里褪猛。
- 部分自定義View 即直接在 ViewController 中呈現(xiàn)网杆，也可能在 ViewModel 中呈現(xiàn)。
總的說來伊滋，就是相同的事件沒能在同一個地方處理弄抬，顯得有點亂票罐，不利于后期的開發(fā)和維護弄屡。
MVC （四） 就是為了適當?shù)慕鉀Q這些問題而產(chǎn)生的好唯。
MVC （四）
- Controller ： 可以說主要用于跳轉(zhuǎn)事件
- View： 更新和呈現(xiàn)視圖，所有視圖都在整個里面筒主，相當于 self.view关噪。
- ViewModel: 數(shù)據(jù)的請求鸟蟹，以及部分邏輯事件
- Api: 網(wǎng)絡(luò)請求的配置
- Model：數(shù)據(jù)的Model 化（轉(zhuǎn)化）
- Other： 管理類以及一些工具
這是我們組長按照他的思路逐一實踐出來，雖說不是很完美使兔，暫時來說還是適用我們項目的建钥。
注意此處的 View 是相當于 ViewController 中的 self.view 的，所有的視圖都以其 SubView 呈現(xiàn)虐沥，這樣也方便后期的任意添加 SubView, 當然此處很多 SubView 是自定義的熊经，需要再單獨抽離出來的。
當然它也是有一些問題的欲险，例如最大的問題就是 可能 View 中會比較臃腫奈搜，里面的事件比較多。
實際上盯荤，我在想后兩種應(yīng)該屬于 MVVM 的變種，但是又有點不恰當焕盟，不知道怎么命名秋秤，但無論如何都是以 MVC 轉(zhuǎn)換過來的，所以暫且這么歸類脚翘。
至于具體項目用哪一個架構(gòu)模式呢灼卢？我個人認為中小型項目是侵向第二種模式的，但我們現(xiàn)在的項目確是適用 第四種模式的来农，雖說第四種模式實踐的還不多...
另外真心覺的架構(gòu)模式這塊要看自己項目的業(yè)務(wù)邏輯和大小的鞋真，繼續(xù)發(fā)現(xiàn)中...
如有朋友對這塊有好的意見和想法，歡迎一起探討沃于！
