iOS軟體開發架構理解

標籤：

這個東西是硬傷，架構？內建的mvc？ 內建的UIViewController UIView UINavigationController 這些算不算？當然算的，cocoa架構嘛，大家都知道。

其實，我想分享的是：整個軟體設計的代碼結構管理。在閱讀了不少源碼後，總結出來的好的設計代碼結構分布邏輯。

一開始，我們學會了簡單的使用UIButton，UIImage等這些常用的視圖類的時候，我們其實已經能夠寫出來一般的軟體了。常見的功能，這裡添加一點，那裡添加一點，這裡一個網路請求，這裡一個bool類型判斷，例如常見的：isDownding? reLoading?

這些，我們經常在ViewController中就直接寫了，於是，飛快的打出來：@property(nonatomic, assign)BOOL reLoading; 然後代碼中，多處引用的地方進行處理。

而如果加上一個網路請求，資料柔和，加上幾個成員變數，NSArray， NSDictionary, 什麼的，再接著，多上幾個又臭又長的正則匹配什麼的。可以想象，這個ViewController已經非常長了。示範：

好了，我們開始來改進代碼了，第一步，把基本的view獨立出來一個view檔案的存放，分離出來。這樣子至少省了3分之一的代碼，再viewController中，而且極大的提高了代碼閱讀效率。直接看viewController就能看完整體邏輯。而可以先不管具體實現。

然後接著，我們又覺得還是不夠，不夠精簡。對。於是，我們把資料獨立出來。對抽象獨立出來。建立專門的Object Storage Service資料對象。可以發現，無一例外的，所有的大型軟體都會這麼做。也可以省了好多代碼，提高閱讀代碼體驗，極大的解耦了代碼。這兩種方法相當的基礎，基本上做完了。至少代碼可閱讀了。入門了。現在的檔案結構是這樣的：

好看了好多。

好了，我們已經基本排版好了檔案結構以及基本的代碼分布問題。但是，這隻是入門了而已。

下面的就是基於軟體的複雜度需求進行變更的：

1.抽離出來網路請求的部分：

　　原因如下：a.網路請求，總會有錯誤返回碼，能方便的增刪查減，代碼更容易找。

　　　　　　　b.網路請求，雖然內建的網路請求也是可以一句話，BLock返回處理結果，但是，要基於自己的商務邏輯進行封裝，一定程度上減少藕合度，提高複用性。

　　　　　　　c.對於特俗的網路請求，例如http的post請求，就需要自己獨立進行封裝資料格式了。

 

2.基於資料的複雜度，進行相應處理，可以添加自己的商務邏輯的資料庫處理操作。可以添加各種自訂類型的資料類。這樣做的好處，也是抽離代碼，減少耦合。

最後上傳一張前人總結的，僅供參考的圖片：

這裡的分類方式真的只能僅供參考，具體情況還要基於實際項目的分析，不能一概而論的。

That‘s all。

iOS軟體開發架構理解