歡迎加入【ios/swift/oc開發***|127183325】交流學習。
公司專案的1.0版本已經結束有一段時間了，2.0版本也逐漸進入尾聲，從1.0版本結束就計畫著寫一下專案總結，一是對專案進行一下思路梳理，二是總結一下之前的工作，找到所遇到的問題和架構的不合理之處，為接下來的版本做準備。由於2.0版本的任務比較緊急，一直沒有時間做個系統的整理，只是零零星星的做了一些備註、筆記什麼的。因為個人原因，準備回濟南發展，所以向公司提出了辭職。利用這段準備移交工作的時間做了一下專案版本1.0的總結，希望能為新來的ios同事快速進入狀態提供一些幫助。
由於專案還沒有上線，所以許多東西都需要保密，可能會有部分比較敏感的部分不會詳說。另外，由於專案後台是公司內網，本文主要講講架構的設計思路，具體的技術細節和**就不往上貼了，有時間可以另開一帖詳談。
1.0版本的專案總結分成以下部分：
一、從架構談起--架構的分層和功能邏輯的細分。
二、關於可復用性和可擴充套件性。
三、block和delegate的抉擇。
四、關於第三方庫
五、框架的進化--框架的持續優化
一、從架構談起--架構的分層和功能邏輯的細分。
對於第一款從零開始主導開發的專案，在開始之前做足了功課。雖然還是有缺陷，但是架構不就是在不斷的試錯改錯中逐漸完善的嘛（給自己找了乙個好藉口。。。）。
先說一下架構的原則，參考之前看到的一篇文章，文章裡面比較詳細的討論了在架構設計中的一些關鍵原則。對此做的總結如下：
1.需要分層，將複雜的系統分解成比較容易實現的較小系統。
2.層內部高內聚，層與層之間低耦合，層與層之間的訪問是透明的，不需要了解實現過程。
3.職責單一原則，職責分工需要明確，邏輯盡量細分，依賴關係盡量少。
4.敏捷開發中需要思維收斂，不要做過多的發散，只設計必須的內容。
5.功能模組化，模組與模組之間也不需要了解實現細節。
6.優先考慮專案的擴充套件性和可伸縮性，效能在初期不必過多考慮。
先看一下此次專案的分層架構設計圖。
從上圖可以看出，各層之間資料的流動嚴格遵守著規則，就是必須要通過業務邏輯層來進行交流。而各層的功能都是基於底層的功能之上，層與層之間的交流通過設計好的具有一定規則的介面來進行，不用關心具體的實現，因此在業務邏輯發生變化的時候就可以將修改的範圍降到最少。層與層之間只能與鄰近的層進行互動，不能跨層呼叫。每一層內部又進行功能模組的細分，模組與模組之間的互動也必須有一定的規則，模組內部高內聚，模組之間低耦合，模組與模組之間關注介面，模組內部關注實現，模組內部的修改不會影響其他的模組。
分好層之後就可以著手進行具體的開發了。一般是從底層開始，最後實現view層。本專案中每層的實現的功能：
1、datapresentation(資料持久層)：資料的**。資料**有資料庫、伺服器和記憶體快取，根據資料**設計dao、net和datacache三個模組，三個模組分別有自己的實現資料訪問的介面，然後通過統一的datapresentation層向上部提供資料訪問的介面。上層不需要了解資料是怎麼獲取到的。
2、businesslogic(業務邏輯層)：核心業務邏輯，一般需要很高的復用性。業務邏輯層用來處理從view層傳過來的資料，處理完成後或者從底層資料層獲取相關資料然後更新到view層，或者直接更新view層，或者將相關資料儲存到網路伺服器或本地持久化或者快取到記憶體中。
3、view(檢視層/表示層)：資料的展示，處理繪圖、點選或者手勢等事件。
下圖體現了在此專案中實現資料持久層各模組之間的邏輯關係。
資料持久化的可選方案主要有屬性列表、物件歸檔、sqlite資料庫和core data(實質上也是sqlite)。此次的專案選擇使用sqlite資料庫，使用fmdb這個十分優秀的第三方庫。順便說一下，在敏捷開發中，非常重要的一點是產品的快速迭代，然後不斷地試錯，不斷地進化，速度是很重要的，所以可以選擇一些比較成熟的框架來用，這比自己重新實現來的要快。在使用第三方庫的時候有一點需要切記，由於第三方庫是由其他的開發者開發的，第三方庫提供的一些介面有可能在將來會發生改變，所以我們不能將第三方庫的介面散落到專案的各處，我們需要在它們的上面封裝一層自己的介面，以備將來第三方庫的介面改變或者替換其他的第三方庫。
1.http，主要用在了和伺服器的互動，由於一開始看的mj大神的教程，所以在設計這一模組的時候深受其影響。因為感覺block是如此的好用，所以就在此處大量的使用了類方法和block，導致1.0版本在擴充套件性上大打折扣，後期更改需求的時候明顯感覺到困難。也因為如此，在進行2.0版本設計的時候基本上是對這一模組進行了完全的重構，明確了哪些地方用block，哪些地方用delegate。所以，雖然block和delegate在功能和所要解決的問題比較相似，特別是block在可讀性方面可能比delegate更有優勢，但block並不能完全替代delegate。更詳細的用法可以參看這篇文章。
記憶體快取在1.0版本中設計的比較簡單，使用了單例設計模式，看下圖：
有記憶體快取機制的時候，必須要考慮記憶體警告和快取資料過期的情況。
因為在資料持久層有三種途徑可以獲取資料，所以就得設計一種訪問資料的機制，或者說規則，比較通用的機制如下：
這張圖只是展示了獲取資料的乙個過程，在從伺服器獲取資料後需要將資料在本地快取，快取兩種途徑，乙個是本地持久化，即存入sqlite資料庫，乙個是記憶體快取。
好了，資料持久層的設計就到此為止了。當然，這樣的設計肯定會有缺陷存在，但是不怕，我們可以在以後的版本迭代公升級中逐步的進行完善，我相信，只要我們不斷的找出在設計上的問題然後改正，最終我們會構建出乙個優秀的框架。
專案總結 Version 1 0（三）
可擴充套件性決定了專案能走多遠，可復用行決定了專案走的是否輕快。本文主要討論1.0版本的專案在進行設計時對可復用性和可擴充套件性的思考，涉及了整個專案分層的所有層 想查閱分層相關部分的可以點這 專案總結 version 1.0 一 和專案總結 version 1.0 二 由於經驗有限，做過多的擴充套...
Java模擬實現伺服器（Version 1 0）
自己動手寫乙個伺服器，不能說水平會有多大的提公升，但是讓我知道servlet是如何與伺服器進行互動的。現在將簡單的模擬實現記錄下來。此處記錄的是伺服器模擬的簡易版本，以後還會寫乙個利用註解實現的伺服器版本 分析圖 判定引數 if paremter null 將引數放入map集合中 parsepare...
Re 評分規則 Version 1 0發布
quote 先見之明 quote quote 前525年，魯 鄭等國上空出現彗星，喜歡賣弄巫術的裨灶推測宋 衛 陳 鄭四國將要同時發生火災。他請求子產用瓘斝玉瓚祭神以禳除火災。子產沒理會他。後來宋 衛 陳 鄭真的發生大火。裨灶便放出話說 不採納我的建議，鄭國還要發生火災。國人很害怕，懇求子產聽從裨灶...