一、本文檔的寫作目的
App需要跟產品、UI、后台、服務器、測試打交道，app的產出是其他端人員產出的綜合體現。與其他端人員溝通就像是開發寫接口，也就是面向接口編程的思想。
本文檔講解針對的是服務端返回數據時使用的字段數據類型如何選擇、iOS端將JSON數據轉模型的時候用什么類型來定義對應的屬性。
二、本文檔的使用范圍
首先介紹下在本文檔中使用的技術領域。
1、服務端使用的是C#語言
2、Api接口文檔自動生成
3、采用的是JSON數據傳輸格式
4、iOS使用的是Objective-C語言舉例
上面提到的技術范圍並不影響到本文檔的推廣。首先，在項目內部嚴格執行。后續可以在公司其他項目組中結合實際情況完成落地。
三、正文
| 服務器返回的類型 | 使用領域 | iOS端模型中屬性類型 | NSLog輸出格式 |
| integer | 表示整型數據 | NSInteger | %ld |
| decimal number | 數據相關的最好使用浮點型 | CGFloat | %f、%0.2f |
| boolean | 判斷是否的數據 | BOOL | %ld |
| string | 文本信息 | NSString | %@ |
| date | 時間信息（要求服務器的dateFormat統一） | NSDate | %@ |
| Enum | 枚舉 | Enum | %ld |
| 對象 | 里面的內容多處使用，封裝成對象 | Model類 | %@ |
| Collection of string | 基本數據類型的集合 | NSArray<NSString *> | %@ |
| Collection of 對象 | 對象類型的集合 | NSArray<類名 *> | %@ |
簡單的表格羅列出來的信息總是意猶未盡，有幾個重要的信息說明如下：
（1）使用NSInteger、CGFloat、BOOL，而不要使用int、float、double、bool甚至是NSNumber。
解釋：
首先，不使用int而使用NSInteger等是屬於語言特性邏輯，NSInterger對int多了處理，比如會結合運行平台使用int_32\int_64。
然后不使用NSNumber的原因是，NSNmuber采用的是類簇裝箱拆箱，NSNumber只是中間量，表述不清楚。JSON轉字典再轉模型，OC語言中字典中的的元素必須是對象類型，因此使用NSNumber放置在字典中，但是在字典轉模型的時候不還原它的裝箱前的本來面目，對使用該模型的開發人員不友好。
（2）關於date類型的說明。
解釋：
date類型通過JSON數據傳輸時是字符串類型。它的由來是，首先服務器用date類型表示時間類，時間類中包含着很多的信息，需要通過dateFormat時間表述格式轉換成字符串類型返回。JSON轉換成字典的時候，date在字典中是NSString類型，iOS端需要還原它的本來面目。但是在轉換成NSDate的使用需要知道之前date轉string的時候使用的dateFormat，因此關於dateFormat需要要求服務端開發人員統一規范（比如我們公司使用的是"YYYY-MM-dd HH:mm:ss"）。
在開發過程中容易在date這塊出現模糊出現動搖，比如產品上的要求是將兩個時間合並在一起顯示（2018年10月10日 6:00 - 18:00），這種情境下服務端是將兩個date字段返回呢、還是將顯示的內容拼接好之后使用string字段返回呢？其實，原則很簡單：服務器返回數據到客戶端的目的無非就是兩個，第一個目的就是為了顯示，另一個目的就是為了客戶端做邏輯判斷。在這里，如果客戶端不需要使用“開始時間”或者“結束時間”做業務處理，那么就讓服務端做好拼裝用string返回，客戶端拿到這個數據之間顯示。相反，如果客戶端需要使用“開始時間”或者“結束時間”做邏輯判斷，那么就用兩個date字段返回，拼接顯示的事情交給客戶端處理。
關於時間信息采用什么數據類型，另一種方案就是全部使用時間戳，采用integer類型返回。兩種方案都可以，統一好就行。
（3）關於Enum類型的說明。
解釋：enum類型本質上就是int類型。為了體現枚舉字段的枚舉性質，iOS端需要在模型上創建一個同樣的枚舉類型。這一點無需置疑，但是在實際的項目開發中依然會出現一些搖擺不定的方案。以下舉例一起搖擺不定的例子，后面會給出一些建議方案：
比如，訂單狀態這個字段。
之前接口中使用的是枚舉字段，iOS端通過enum定義枚舉類型。
后面產品上的設計需要將訂單狀態對應的文本（比如1-“未支付”、2-“已支付”等）顯示在界面中。iOS采用的是本地硬編碼的方式，將枚舉值與文本對應起來。
但是當產品上的設計需要將“已支付”改成“完成支付”顯示的時候，硬編碼肯定是不行的。所以接口中增加一個訂單狀態的string類型用來顯示其對應的文本內容。
再后來，服務端同學覺得兩個字段可以合並為一個對象模型（keyValueModel類，屬性key：int，屬性value：string），至於枚舉的種類，在字段的說明區域顯示。
使用keyValueModel類一段時間后發現，枚舉的范圍增加后，服務端同學容易忘記在字段的說明區域編輯了，或者是枚舉值十多種之后，顯示不下（顯示不雅觀）。
其實這個問題很好解決，還是使用上面提到的原則。使用兩個字段，枚舉字段用來供客戶端的同學做邏輯判斷、string字段用來供客戶端的同學做界面展示。
四、總結
根據“服務器返回數據到客戶端的目的無非就是兩個，第一個目的就是為了顯示，另一個目的就是為了客戶端做邏輯判斷”的原則，結合產品的設計需求，作出統一化的處理。