iOS開發 - 網絡&數據庫功能綜述

學習經驗尚淺，之前iOS開發一直停留在單機版的開發，可是如今若是一個移動端開發徹底拋棄網絡功能，它也不會存在好久。網上講的關於iOS的網絡部分都比較專注，這兩天通過融合和總結，大體摸索出了一套總體流程，在此和對網絡鏈接不甚明瞭的同窗分享，本文不涉及技術層面，只是概念的串通。

前提注：若是你真的只是開發一個單機版app也或者公司已經將網絡數據封裝好給你個接口or XML格式等文件用並且也不想知道的話就請華麗麗地忽視我吧。

 

1、前提概覽

首先，要考慮app所在的大環境是個什麼級別的環境，我大體將環境分爲如下幾種

1. 我的開發，單機版app

此時若是沒有數據交換存儲的話，忽略這篇文章

若是有數據存儲和操做的話，用coreData/NSArray(NSDictionay)，這種狀況下幾乎是不須要直接操做SQLite的（優勢以後說）

2. 我的開發，網絡版app

此時若是沒有網絡數據存儲，好比只是將某個板塊作成了地圖並且只是展現地圖數據，只須要用好MapKit or Google API便可

若是隻是簡單獲取一些商家封裝好的網絡數據。好比獲取iTunes的訂閱等，須要的是用好XML解析功能（NSXMLParser，第三方框架）or JSON解析功能（同理）

若是在以上兩條狀況下須要對數據進行增刪改查，須要用到服務器交互或者本地coreData（不建議直接操做數據庫）

3. 團隊開發，單機版app（真的是純單機版）

我認爲這種狀況不太可能

4. 團隊開發，網絡版app

這種狀況也適用於我的想開發配套web應用的狀況

此時若是web方面以及服務器交互方面由團隊其餘人在作，作好本身的事情便可

若是是我的想作全棧的活，還須要至少了解網絡協議以及熟練使用至少一門服務器腳本（好比PHP, Node.js等），SQL，其次能夠考慮web前端作web版配套應用。再用java等編程語言作業務邏輯對於一個我的開發者來講工做量太大了，若是必定要這麼作，你真的須要考慮組建一個團隊···

 

對於以上狀況，我下邊總結的都是關於我的開發者的一點經驗，一個專業團隊中，專才更重要，而不是全棧工程師

 

2、網絡數據操做

這個部分只是關於網絡數據方面，與服務器和數據庫無關。

一種是現成的封裝好的網絡數據，好比MapKit和Google Map，這樣熟練運用其框架就可實現大部分功能。

一種是商家提供的數據交換格式XML, JSON, RSS等，此時作的是學好XML解析（自帶NSXMLParser，或者GDataXML等第三方庫，網上建議使用第三方庫，自帶的解析有些繁瑣，我不否定第三方庫更簡單明瞭，可是NSXMLParser更能體現SAX解析方式的思惟套路），JSON解析。如今主要就是XML, JSON這兩種格式，大公司都有JSON格式給你，可是也不能避免一些你確實想用的數據公司只提供了XML。

此處由於我以爲團隊不夠級別時，第三方公司不會給你自主交互服務器的機會，可是會給你API操做。更況且是我的開發，主要仍是以操做數據交換文件爲主。

 

3、網絡操做帶有服務器和數據庫

闡述一些基礎概念，由於iOS開發嚴格意義上來講只是客戶端的開發，服務器數據庫部分只是錦上添花，因此有些像我同樣的新手只作過web，iOS開發的童鞋，對於總體流程可能沒有認識。尤爲是移動端，一個公司不會用移動端開發操做後臺的平臺的吧。

最終得到網絡數據庫數據的途徑有兩種

1. 客戶端 - 數據庫 模式，這種方式通常狀況是很是不推薦的，一是由於直接操做數據庫代碼繁瑣，不宜更新維護，好比大量的鏈接關閉操做，sql操做，當表中屬性信息改變時，改動工做量很大。二是這樣一來數據庫的藉口信息將暴露在客戶端中，不安全，數據庫必定放在大後方。

2. 客戶端 - 服務器 - 數據庫 模式，這種模式纔是正常的模式，服務器封裝了對數據庫的操做，只用對服務器發出請求再收到迴應數據便可。此處發出請求的方式爲GET/POST兩種主要的方式，前者有字段長度限制，屬於經過url操做得到數據，後者屬於將request發送到服務器，服務器通過處理request給出一個response返回給客戶端，這種方式比較經常使用，理論上不考慮服務器的運算能力，是沒有容量限制的。GET只適用於獲取少許數據，由於你不能把大量數據，好比視頻，放在某個url指向的文件中供調用吧。POST便可通過服務器的封裝運算，更有效地操做大量的數據，好比視頻的上傳下載等，具體請查閱相關文章。

 

其次我將數據分爲如下幾種狀況

1. 數據只須要進行單機操做（少許）

通常數據存倆NSArray or NSDictionary得了

用戶登陸信息的Cache經過coreData存儲在本地（第2點詳述）

 

2. 數據庫只須要進行單機操做（大量）

此時coreData是首選，說明一下coreData並非數據庫，是一種數據持久化技術，哈哈這種概念聽多了和沒聽同樣，通俗來說，coreData是蘋果對SQLite數據庫的很好的封裝，開發者經過coreData能夠更有效的操做SQLite數據庫，至關於程序和SQLite的中介。

因此此處也應該明白了一個有可能困擾新手的問題，coreData和SQLite有什麼區別？

若是對於coreData和SQLite自己來說，不是一種概念，由於最終操做的都是SQLite。非要說區別，指的是操做coreData和直接操做SQLite有什麼區別。coreData是將SQLite進行對象化而後進行操做，若是對Oracle或者mySQL有經驗的童鞋，不難理解數據庫實例化的意義，畢竟如今什麼都流行面向對象嘛！coreData的優勢就在於彷彿是鏈接你的MVC程序和SQLite的服務器，對數據庫進行封裝操做，在SQLite表的屬性有所改變or換了一個數據庫實例什麼的，可以進行方便的數據轉移。直接操做SQLite通常狀況下既繁瑣又難以維護，可是若是你須要對數據庫進行高級操做，coreData也許知足不了你，這時就須要撇開coreData直接操做SQLite。

CoreData還有一個最大的優勢就是經過NSFetchedResultsController以及其delegate方法，能夠實現當增刪改查數據庫時對頁面顯示數據的實時更新，好像AJAX哈哈

 

3. 數據須要在網絡上進行數據交換（少許，公開）

這種狀況下，我認爲目前移動端並無用來作服務器和數據庫的後臺開發，因此通常來說除了用戶信息和某些特定行業app（好比銀行等），大部分數據都是公開的網絡數據，用數據交換最靠譜，優勢就是簡單，速度快。增刪改查JSON/XML的操做在iOS中能夠實現。

這時首選是JSON，後起之秀，輕量級數據交換格式，簡單易用，思路也清晰，在iOS開發中非常推薦

若是沒有，選用XML的輕量級第三方框架好比TBXML，GDataXML等，第三方框架多用DOM方式解析，比原生態的快不少，可是隻是在處理少許數據時，詳情在這裏

http://mobile.51cto.com/iphone-281283.htm

 

4. 數據須要在網絡上進行數據交換（少許，安全傳輸）

這種狀況最多見的莫過於用戶登陸驗證了，此時須要與服務器進行交互，發送HTTP請求（POST，POST安全，由於須要通過服務器處理）

最老的NSURLConnection（已經deprecated，並且在主隊列操做，太慢）

iOS7以後推薦的NSURLSession（能夠異步處理，詳情點擊這裏，個人另外一篇文章）

第三方AFNetworking（與NSURLSession同理，我我的測試以爲是最快的）

ASIHttpRequest，當年很牛，可是好久沒有更新，前兩天用了一下，若是你的程序開啓了ARC模式，已經不能用了，由於這個框架是在手動控制內存的時代寫的

這時不要想如何與數據庫直接鏈接操做，你這樣等於把全部用戶信息暴露在了任意一個移動端中

 

5. 數據須要在網絡上進行數據交換（大量，公開）

Num 1. 你須要大量數據中的一部分。若是是數據交換的方式作，JSON和XML的DOM級別框架也許知足不了你了。這時候推薦水果自帶XML解析NSXMLParser，libxml2，支持SAX解析，SAX和DOM的區別以及NSXMLParser的基礎實現點擊這裏，我寫過一篇。

Num 2. 你須要大量數據中的某一條。請向服務器發送請求（此時XML，JSON代碼可能會比較冗長）。非要連數據庫，就把數據庫的接口信息當作服務器接口信息來作，而後進行相應的增刪改查。

Num 3. 你須要大量數據的全部，也許XML DOM方式以及JSON會快一些，我沒測試過大量數據。

 

6. 數據須要在網絡上進行數據交換（大量，安全傳輸）

這在移動端應該是見不到的，那就是內部web項目的事情了。

 

本文旨在給iOS我的開發初學者作一個簡單易懂的網絡指南，若是有錯誤請不吝指正。

 

若是你對搭建網絡服務器和數據庫有一點興趣，在評論中告訴我，我以前搭建了一個AWS EC2 配 AWS RDS的小系統，以後會寫點這方面的心得。

 

歡迎光臨個人主頁http://www.jiachengzhi.com/