Minya 分層框架從某種程度上來說，基本達到了一些預期目標。回顧一下第一篇中的目標：
-
明確每一層的職責；
每一層專注於自己要處理的事情，而不用向外提供方法或回撥來傳輸資料。View 層專注於檢視的展示及使用者輸入的捕獲；
ViewController簡單維護View和Store，更專注於頁面的跳轉、轉場動畫等操作；Store層專心處理資料。將各層間資料的傳輸任務交由pipeline來實現，各層物件只需要監聽其中的資料變化或往裡面寫資料就行；另外，通過
pipeline可以簡化深層次檢視資料外傳的問題，避免通過層層Delegate將資料傳輸到ViewController。 -
輕量化
ViewController，讓其成為資料的中轉站；ViewController不再需要詳細地瞭解View和Store的細節，不需要作為View的Delegate，也不需要呼叫Store的網路請求方法並在回撥中運算元據；而是把更多的精力放到了頁面跳轉中。 -
將業務處理獨立於一層，並可根據實際情況將業務細分到不同的類中進行處理；
所有的業務邏輯都在
Store層來處理，如果一個Store處理的業務邏輯過多，可以將程式碼拆分到子Store中處理。 -
均分程式碼，確保一個類或檔案的程式碼量不會太大。
然而，正如一個硬幣的正反兩面，有些方案帶來便利的同時，也會引入負面的東西。
- 一次複雜資料傳輸流程的程式碼過於分散（正如上一篇的例子），可能會在多個類中，不直觀，很容易就跟丟了中間流程。這對於除錯和後期維護來說，是一件很不友好的事；
- 對單元測試不友好；
- 對於複雜的頁面不夠友好，如果說美團首頁這種頁面，需要構建複雜的
pipeline層級結構，這可能會導致pipeline過於臃腫。實際上，如果處理不當，恰恰有可能導致複雜化pipeline，對View、ViewController和Store的簡化，最終可能實際上是轉嫁了複雜性； pipeline的劃分程度決定了pipeline類的數量，所以有可能引入大量的類，導致類爆炸。同樣，Store層及下面的Service和Storage也有同樣的問題；pipeline中屬性的設計順序可能影響到操作是否能正常進行，如登入頁面，需要先將username和password放入pipeline中，然後再設定點選按鈕的 flag；如KVO對集合型別的支援不友好，pipeline中需要額外的標識位來標識列表資料的變更；- 降低了原有的依賴，而沒有消除依賴，反而是建立了新的依賴，引入新的不確定性；
- 框架依賴於定義好的幾個基類和介面，所有對擴充套件有一定的侷限性；
Scene物件減少Objective-C的#import操作的同時，增加了硬編碼。這對於重構來說並不友好。
鑑於以上問題，以及 MVVM + RAC 的優越性，我們後來將整個技術棧切換到 MVVM + RAC 上，同時將 MVCS + Pipeline 這一套不成熟的框架開源，以供大家參考。
知識小集公眾號
知識小集是一個團隊公眾號，每週都會有原創文章分享，我們的文章都會在公眾號首發。知識小集微信群，短短几周時間，目前群友已經300+人，很快就要達到上限（抓住機會哦），關注公眾號獲取加群方式。