iOS 架構（起手式）

以前有對iOS認知中作過一次簡單的分析 http://www.javashuo.com/article/p-sprspyls-dz.html

既然說是架構：那麼這邊要考慮到的是整個項目，若是是一個層次簡簡單單的項目，對於架構來講也沒有很是大的體現意義，我的認爲，架構就是能爲 業務邏輯複雜的項目塑性，好的架構不只層次清晰，開發過程也應該是愉快輕鬆的，不是重複的碼代碼！ 先從大的方面來說： 一個App分爲 網絡層(Server)、數據庫層(DataBase)、 應用層(Application) 三者之間的關係，如上圖所展現

三者之間關係的實現：採用經典的工廠模式(ServiceFactory)來鬆耦合：以不一樣的功能模塊來劃分，如： 圖中Sevice是提供了獲取系統權限和用戶邏輯相關的接口服務，隨着業務的增長，項目不斷的完善，Service會不斷的龐大起來，通常以功能來增長不一樣的服務。 網絡層指的是:和服務器的交互，通常封裝了第三方的網絡實現，一個方法一個CallBack，在Service中的某個功能下的Protocol實現； 數據庫指的是：用戶對數據的操做或響應服務器作出響應修改，通常底層都作了封裝，暴露出行爲功能的接口（增刪改查等）

下面來講下一個重要的類UIResponder： 其中這張圖片包含了一個重要的思想，事件追蹤，它能夠在咱們觸發的那個類裏，發出事件信號，能夠一直追蹤到controller這一層。 這在咱們寫業務的時候，是個很是巧妙的事情。

接下來從小的方面Controller來解說架構： 一個App也是由多個Controller的組合而成，Controller最重要的是UI元素、邏輯和交互。如何處理好這些關係相當重要。咱們如今比較流行的架構是將邏輯(presenter/businessLogic)和交互(interactor)分離出Controller，避免了Controller的臃腫，也有將View分離出去的。（架構VIPER，CDDContext等） 站在了已有的架構的基礎上，作了一些修改。

如上圖，PBMainController是一個主界面，裏面也按Presenter、Interactor和View來劃分，可是這裏比正常的架構多了一個Protocol文件，這個是對應於Controller、Presenter、Interactor和View，增長這些協議類，是爲了下降這4者之間的耦合度，由於在實際開發過程當中，隨着項目的迭代，類會愈來愈龐大，代碼量也愈來愈多，若是將類的public方法或屬性都寫在.h中，代碼的安全性就更差，團隊中的其餘成員可能在不清楚你的代碼塊的做用下，就修改了代碼，這邊就將類於類之間的邏輯關係都寫到了Protocol中，在對應的.m裏去實現。

在Controller.h中對應的Presenter、Interactor和View都是readonly屬性，這樣能保護它們不受外部類影響，且他們對應的baseController都是指向當前的Controller，其餘子View能夠經過UIResponder的特性獲取到指向當前的Controller；

在上面的Main結構圖能夠看到：PBTestSubView是PBMainView中的一個view, testButton是PBTestSubView中的一個UIButton，那麼點擊testButton，跳轉到另一個界面，正常的App多是經過兩個Delegate或者NSNotification來實現。可是若是用Protocol和baseController來實現，那就是在testButton點擊的時候，能之間將事件傳遞到指定的Controller，再獲取到對應的Interactor，這樣的實現是否是簡單不少？

咱們利用UIResponder的特性，能夠在任何一個它的子...子控件裏追蹤到存放它的當前Controller，從而實現界面跳轉。這樣代碼看起來是否是很簡潔明瞭？層次也是很清楚。

總結：站在前人的基礎上，修改了下架構，仍是比較容易的。 這個架構的思想： 大的方面是工廠模式，Service 管理了 數據層、網絡層、和應用層之間的關係。 小的方面利用UIResponder、Protocol 結合以前網絡上的框架來鬆耦合。 架構層次很明顯，主體框架代碼咱們能夠寫個腳原本生成，這樣能夠避免大量碼代碼的時間，並且也不易出錯。

在gitHub上給出了一個Demo

碼雲訪問地址Demo

Demo中應該能看到這個架構的整個思想，具體的數據庫和網絡的管理也是要分層的，它們應該在service下面的,demo中沒有寫了，有時間後續會完善demo。