項目總結--Version 1.0（三）

可擴展性決定了項目能走多遠，可複用行決定了項目走的是否輕快。

       本文主要討論1.0版本的項目在進行設計時對可複用性和可擴展性的思考，涉及了整個項目分層的全部層（想查閱分層相關部分的能夠點這：項目總結--Version 1.0（一）和項目總結--Version 1.0（二））。

       因爲經驗有限，作過多的擴展容易誤導其餘人，因此本文所作的一些討論總結只限在本項目範圍內進行，對這個項目在進行架構設計的時候遇到的問題和本身的一些想法在此作一些梳理和總結。

一樣的，先從最底層－數據持久層開始提及。先看一下數據持久層的類結構圖：

數據持久層類結構圖

 

先分別說一下上述類的做用。

FBServerTool是一個單例，在程序運行的時候就進行初始化，這個類將手機端變成一個服務器，以供設備端對手機端的主動鏈接，在2.0版本中將此功能移除。

FBSocketTool一樣是一個單例，也是在程序運行的時候進行初始化。這個類承擔了兩個功能，一是發送UDP包，二是提供一個TCP鏈接。

FBHTTPTool是一個封裝了AFNetworking的類，它提供了訪問web服務器經常使用的靜態方法，相似AFN，使用了Block回調方式。

FBSOAPTool封裝了SOAP協議，SOAP協議是數據交換協議的一種協議規範，基於XML。更具體詳細的介紹能夠看這：SOAP。經過這層封裝，咱們在使用SOAP協議的時候就能夠沒必要關係具體的協議規範，像使用普通的HTTP來用便可。

FBWebservice包含了網絡相關的宏定義，包括接口地址和Web Service使用的服務和方法。將相關的宏定義放在此處能夠很方便的進行修改。

寫到這你們應該能看出來某些地方感受特別不爽，沒錯，我在開始2.0以前看這部分代碼的時候也有這種感受。到底哪出問題了呢？先看一下類名，＊＊＊Tool，第一眼看上去感受這應該是一個工具類，裏面的一些方法應該是類方法，但實際上，除了FBHTTPTool，FBSOAPTool，FBWebservice外其餘類都是單例！這就有問題了，命名不規範，這會致使其開發者在用到咱們這些類的時候須要進入類裏面以後才能理解咱們是如何設計的，而不能從名字來進行大概的推斷哪些是單例，哪些是普通類或者相關的工具類。這在其餘開發者分析項目，閱讀代碼的時候會增長沒必要要的時間成本。

另外，根據單一職責原則，FBSocketTool類的功能還應該繼續進行拆分，在2.0版本中，這個類分紅了兩個類，一個負責UDP報文收發，一個負責TCP報文收發。

而後就是FBHTTPTool，這個類在2.0的版本中變化挺大的，由以前的類方法變成實例方法。這個類負責將AFN封裝而後向上層提供簡單的POST和GET方法，網絡訪問的結果在Block中進行處理。

FBSOAPTool和FBWebservice比較簡單，在兩個版本中幾乎沒有變化，在此就略過不談了。

以上是NET模塊的部分，接下來講一下DAO。這個模塊最重要的就兩個部分，一個是第三方庫FMDB，另一個是JKDBModel。FMDB是一個很是優秀的第三方庫，極力推薦你們使用學習。JKDBModel是在FMDB之上又進行封裝了的一個輕量級的小框架，和蘋果自家的Core Data使用的ORM（對象關係映射）技術比較像，它將類名和數據表，屬性和表字段進行映射，可以自動建立數據庫和數據表，自動添加新增的表字段，避免了繁瑣的SQL語句書寫（雖然有時仍是須要些一部分，但已經大大減小工做量了）。源碼比較簡單，你們能夠拿來看看，學習一下，做者的思路仍是很棒的。

最後說一下數據緩存這一塊，這個地方應該是個人硬傷所在，整個項目看着最不順眼的地方就是它了，在設計這一塊的時候沒有敢設計的很複雜，只是實現了基本的功能，因此數據緩存這一塊還須要花時間專門研究一下。設計思路能夠看一下前面的這篇文章。

我在進行着一層各個模塊的設計的時候儘可能的去避免了模塊之間橫向的訪問，模塊與模塊之間須要遵循一套嚴格的規範來相互訪問，不要讓模塊之間有太大的耦合度。保持各個模塊的獨立性才能在未來擴展的時候可以比較優雅的實現。在設計NET和DAO這兩個模塊的功能的時候，本着單一職責原則（重複好幾回了，但願你們也可以記住，這個原則對代碼的可複用性很是重要），不要讓一個類承擔過多的指責，將粒度劃分的足夠小咱們才能很好的複用這些已有的功能。

歡迎加入【iOS/Swift/OC開發交流羣|127183325】交流學習