APP架子遷移指南（一）

搭架子是腦垂體在放煙花

俗話說吃多少飯，走多少路，上學的時候捧着《設計模式》就想睡覺，如今輪子看得多了，天然有心照不宣之感。搭架子就像談哲學，如高山流水，遇彎則急、遇潭則深。我印象最深的是一次酒過三巡，一位德高望重的前輩講釋迦牟尼的故事：有人問釋迦牟尼」恆河的沙礫有多少？「，釋迦牟尼答：「恆河的沙礫比銀河的星星還要多。」對科普過的咱們這一比喻看似普通尋常，可是在那時候對宇宙根本沒有多少認識的年代，能作出這樣的判斷，是須要怎樣的大智慧才能辦到？

搭架子就是一個思考恆河沙礫數量的過程，不該被DAL、MVC、MVP、MVVM、DDD、充血、貧血這些術語固化，這些是規範、是交流語言（DDD裏面還專門討論了這個事），目的是爲了讓你或者團隊的其餘人可以看懂你在幹什麼（如PHP中的PSR-X規範同樣），只是告訴你「數沙礫的步驟」；選擇用哪一個規範來完成，纔是思考恆河沙礫數量的過程（好比你直接複製一個MVP的項目模板做爲架子藍本，爲何要複製一個藍本直接用，由於你內心有數這樣作最快、最省事，這就是一個思考過程）。

再舉個例子，劍法巔峯講究「合一」境界，人劍合1、見招拆招、凌波微步，忘記全部劍譜和步數，心指劍到，惟我不破。搭架子，是「人劍合一」的過程，你可能會畫草圖、會寫需求文檔，但都是在心中刻畫整個輪廓；寫代碼，是在重演劍譜，由於劍譜你已經擺了幾百盤，你知道listview須要adapter、tableview須要算高度；用輪子，是在見招拆招，你能夠用Glide或者SDWebImage、或者乾脆直接用AFNetworking自帶的圖片擴展。

架子遷移，是從無序的代碼結構中進行提煉和總結，以MVP、MVVM等思路對代碼進行重構。搭一個架子根本不是性能，而是爲了體現更好的代碼規範和功能擴展（白話就是什麼代碼寫到哪一個文本文件裏面，如Presenter裏面放交互代碼）。

討論以前先明確幾個思路

DDD裏面特別提到過一個觀點我很是贊同--UBIQUITOUS LANGUAGE(通用語言)，就是首先要理清楚咱們究竟是在討論什麼，這樣纔不會誤會，思想才能連貫。好比我說「蒼老師」，你我都知道咱們在談什麼；但我要是說「陸家嘴」，你覺得我是在說那個視頻，我實際上是在說一個地名。這裏套用這一律念，先說說我搭架子的幾個思路。

1.不要用力過分。一個幾千萬把塊錢的項目，就別思考用DDD（DDD是我見過最高深晦澀的架子思路）把業務拆分紅領域而後還要設計接口和工廠了。一個基礎架子的代碼量都比你實際功能寫的代碼量多。 2.不要被MVP、MVVM唬到了。舉個例子，以前你可能會用一個BaseXXX把社交分享、界面初始化的代碼寫在裏面，XXX繼承該類，而後就只須要把某個按鈕的邏輯寫出來，這樣一個文件裏面的代碼行數就降下來了，讀起來就清爽了。MVP、MVVM乾的就是這種事，一模一樣，只是更規範而已。 3.設計模式不是架子。一樣是開發思路，但設計模式是針對某一邏輯功能的實現策略。好比社交分享，你能夠用工廠模式實現QQ、微信、微博（都有個成功、失敗的狀態，只是發送的數據不同），代碼寫在哪一個文件裏面，放在哪一個包裏，就是架子考慮的事。 4. 如今火的不行的RxXXXXXX不是架子，是輪子（更直白的說是技術網紅找優越感的罩杯，MVVM也是，這些在.NET3.5時代就玩膩的東西，拿來還當寶了:P）。響應式編程值得學習，但沒有達到徹底取代Handler的高度。

如今的架子哪裏很差了

APP到底要不要用一種模式來搭架子，是一個須要權衡的想法。APP說白了和Winform同樣就是個展現層（Presentation），作過Winform的都知道，一個DAL三層模式就足以勝任大部分工具軟件的須要了。因此沒有必要把APP開發想象的那麼高深莫測，就是一個網絡訪問-》數據讀取-》數據顯示的過程，用包或者Xcode裏面的group區分業務模塊，就是一種簡單而且特別實用的架子。

初期架構

上圖就是一個典型ios架子，通用工具類沒畫出來，但應該能夠理解（好比時間處理）。一個模塊爲一個Group（如首頁），首頁模塊的代碼按MVC分離，全部功能邏輯所有放在Controller中，有不妥麼？沒有任何不妥，功能一個不落能夠實現，但.M文件就顯得太臃腫了。

分離網絡通訊

上圖作了簡單的剝離，把網絡通訊模塊從Controller中取出來，放在Manager中。Controller的.M文件是否是就感受乾淨多了？其實還能夠繼續剝離，把TableViewCell的數據綁定放到Model中去，把數據庫緩存等寫到一個叫Task的文件中去。從我讀過的不下10個開源項目看來，到這一步，就是如今最多見的架子結構了，代碼複雜程度能夠接受、架子伸縮自如，其餘模塊只是複製加粘貼的問題了。

對Android來說，架子能夠說如出一轍，只是多了一個adapter，Controller變成了Activity或者Fragment。從功能實現上講，有問題嗎？也沒有任何問題。那麼爲何要考慮用MVVM或者MVP模式呢？若是你有強迫症，喜歡把MM豆根據顏色歸類；或者隨着功能的增長或參與人員的增長，你會慢慢以爲Contoller中寫的代碼開始亂套找不到你想要的東西，直覺會告訴你，是時候須要一套基於單一原則的架子來重構項目了。

架子就像寫八股文

在前文討論了UBIQUITOUS LANGUAGE(通用語言)這一律念，常見關鍵字如Manager、Domain、Service、Biz、Helper，其實文件裏面寫的代碼乾的都是一碼事，但都是不一樣架子模型中的術語（如Domain是DDD中的術語）。若是是個團隊，即便見多識廣，也不推薦混淆使用術語，這樣容易形成困惑，有些事情仍是較真一點比較好。另外，各類架子須要基礎代碼或文件來搭建，好比MVP模式中有一個XXXContract文件，定義行爲接口。這些代碼會增長工做量，但卻值得老老實實的建立，由於這些架子基礎代碼能夠更好的執行邏輯隔離和單一原則行爲，讓代碼更好理解。

因此搭架子就像寫八股文，就像寫論文同樣，不是搞藝術創做，你不是詩人。規範的目的就是爲了層次清晰，當你習慣架子規範後，你在看到文件名的時候就心中有數，應該如何繼續如何繼續開發了。

接下來的文章

我在看架子的時候一直對「業務邏輯和功能邏輯要分離」等等很晦澀的話感到困惑，接下來的文章我都但願能經過實例代碼讓你搞明白這些到底是在講些什麼東西。全文以我開源的社交APP「獨白故事」及多個github開源項目爲代碼藍本進行解釋，總結一下本身對架子的理解，順便也把獨白故事更新一下：）