摘要：請求下來數據之后，我們使用了提供的進行解析，類化。示例代碼本篇我們將提供以及示例代碼來闡述我們上文中提到的用法。下一節下一節中我們將針對初創公司端技術團隊構建的一些問題來闡述我們的團隊如何構建以及運作的。

“網絡請求 - 解析數據 - 寫入緩存 - 讀取緩存”

在上篇的文章中我們說明了我們在是在 MVC 層面的 M 層共享了代碼，不過對于只是“有可能”需要 OpenSDK 的團隊來說，更重要的還是保證 M 層的代碼能夠支撐 VC 層的調用方式。我們在編寫界面的時候，通常情況下是先從緩存(SQLite，下同)中查詢該界面已經緩存的數據用于顯示一屏預覽數據，此時在界面上某個角落顯示 HUD，然后發起網絡請求，請求到數據之后解析數據(JSON,XML,Protol Buffers)，然后將數據類化寫入緩存——YES，就這么倆事(兒)，too 易姿 too 森破。

“libcurl & json11”

我們團隊在 Web 上用的是 MEAN Stack，對于 Client 來說，就是發起一個請求，然后獲得一個以 JSON 形式表示的結果，Client 將其解析為類，然后將結果同步到 SQLite 中，方便下一次緩存頁面的使用，在具體的使用中，我們參考 cocos2d-x 對 libcurl 的封裝，并結合 C++ 11，封裝了一個 HttpClient 用于普通的 GET/POST/PUT/DELETE 請求，對于 iOS 和 Android 的上傳和下載部分，我們仍然使用了原生的方法，因為有些時候上傳和下載需要在“后臺”進行，這意味著需要提供能訪問 framework API 的能力，對于 Windows 和 Mac，則可以繼續使用 HttpClient 中提供的 C++ 方法來進行操作 (因為并沒有“后臺”一說)。請求下來數據之后，我們使用了 dropbox team 提供的 json11 進行解析，類化。

“easySqlite”

在數據緩存方面，我們選用了大家都說好的 SQLite，在 SQLite 的方案上我們其實做過一些探討——我們可以選擇 CoreData 作為 iOS/Mac 的方案，Android 也有原生的 Helper，Windows 則只能使用 C/C++ 的原生方案。經過實踐我們發現其實在客戶端幾乎只有讀取緩存的需求——因為寫入緩存的操作可以在 C++ 層面完成——緊接在 HTTP 請求之后，所以我們就選用了所有平臺都使用 C/C++ 的方式進行數據庫操作，查了幾個可選的 C/C++ 庫之后，我們覺得 easySqlite 是比較容易使用和維護的。(輕量是我們評估方案的一個重要參考指標，輕量不僅意味著小，而且意味著 fork 之后我們可以自己進行修改而不用在弄懂里面的工作原理上花過分多的時間)

在緩存策略上，我們就是簡單的將 JSON 解析后類的表存儲到數據庫中。這里有個小插曲，之前有看到有策略是將每個頁面的 JSON 直接存儲到數據庫中，然后取出的時候解析呈現，不過我們的移動端和桌面端有可能調用不同的 API 接口，而且如果按照頁面緩存，就不是一個適合放在 Core 層的方案了，故最終該方案還是沒有敵過我們一顆面向對象的心。

“Sakura”

由于我們在 Worktile Pro 版與 Worktile協同版中使用了同一套的底層工具庫，而 build 過 C++ library 的同學也應該會覺得其實每個平臺看著對應庫的文檔去 build 也是挺蛋疼的一件事情，所以我們將我們用到的 C++ 庫 fork 一份并且編譯出來，連我們一起的弄出一個 prebuilts 作為我們 C++ 的核心庫的工具庫，用 git submodule 形式管理使用。(為了體現一點情懷，我們取名為 Sakura>>)

“人生苦短，我用 Python”

上文介紹的 C++ 跨平臺的目的，是在創業公司初期人少的時候提供一個可以很快出產品的技術方案，在我們編寫一個又一個的模塊時，我們發現我們在做一個比較重復性的事情 ——寫一個 User，寫一個 UserManager 用于管理 User 相關的 API，為 UserManager 編寫一個 FetchUsersFromCache， 用于從 SQLite 從讀取用戶的信息，然后編寫對應的 Objective-C++ Wrapper 以及 Java Wrapper，然后我們編寫一個任務的模塊的時候，我們又重復了同樣的一個過程——當然，細想一下，我們重復做的事情并不能通過在 C++ 設計 Super Class 或者 Template 抽象出來，但是我們的的確確在用一套重復的思維方式，于是，我們將應該由 Contributor 消費腦力完成的設計過程提煉成 module.xml，然后編寫了一個 Python 腳本用于生成 C++, Objective-C++ 以及 Java 部分的代碼>> 。

使用 Model Builder 構建代碼的好處一方面是可以保證全部門的代碼風格統一并且符合規范，另外也可以解決一些由于傳參太多或者重構的時候順序亂了造成的一些低級錯誤。不過需要特別提一句的是，即使使用了 Model Builder，我們仍然認為只有 Unit Test 能保證你的代碼質量，我們僅將 Model Builder 視為代碼構建的輔助工具。另外，因為在我們公司我們無法獲取 Web 端的代碼，如果你所在的公司處在剛起步的階段，你完全可以考慮將 Model Builder 自行擴展下使其能夠生成你們的樣式的 Web 端代碼以及文檔，這樣更讓聯調這一過程變得 smooth (因為返回的 JSON 的 Key 聲明在了 module.xml 中，這樣就可以保證服務端所使用的 path 和客戶端的相同)。

本篇我們將提供 iOS 以及 Android 示例代碼 來闡述我們上文中提到的用法。

下一節

下一節中我們將針對初創公司端技術團隊構建的一些問題來闡述我們的團隊如何構建以及運作的。