Json 一種輕量級的數據通信格式

Json是一種基於js的輕量級數據交換格式,獨立於特定的語言,其中對於信息的保存使用特殊的符合來實現不同的數據結構。可以構建兩種基本數據結構:

 

1、對象

對象的概念類似於面嚮對象語言中的邏輯,採用 key/value的方式保存數據,同時使用{}包含來表示對象;如:

 

{name:'quzishen',company:'netease',department:{d1:'hangzhou',d2:'tech',d3:'dir'}}

 

可以看到,對象中可以繼續包含子對象。

 

2、數組

數組也相同,使用我們習慣的[]包含,如:

[{name:'quzishen'},{name:'dinglei'}]

 

對於java等語言而言,這個json格式的數據其實就是一個字符串,如果使用最原始最古老的方式,你可以使用substring和split兩個方法來不斷切斷解析出其中的字段和值,當然,我們希望的,是通過一個更爲簡便通用的方法,來完成一個轉換,而不是上述的極有可能錯誤百出而無法重用的方法。

對於java語言解析json數據的開源jar有很多,我們使用json.jar來做一個解析工具類,首先下載jar包:

 

http://download.csdn.net/source/2835793

 

針對於json的數據格式,提供了連個對象類 : JSONObject 對象 和 JSONArray 數組。相關的配置內容,提供了一個JsonConfig 來保存相關的配置信息,比如在生成的json數據中,源對象中的哪些字段是不需要的等。

 

所以,我們只用這兩個對象類,以及輔助的接口就可以做一個簡單的json組裝解析工具 

 

 

測試代碼:

 

其實最便利的,是針對於項目的領域模型,做特定的json格式和domain轉換工具,最爲方便。

 

通常而言,對於系統之間的交互,我們多數採用了ws或者esb來進行交互,這是作爲服務器端java開發人員最常用的方式。對比而言,json的方式對於慣用了ws或者esb的開發人員來說,系統之間的通信方式的變更具有很大的逆轉,需要一個適應過程,去琢磨其中的利弊。

首先,ws格式的通信,在soa架構中最爲普遍的應用,通常的soa架構會將系統分級不同層次,比如核心系統,基礎服務,通用產品,業務系統等,這樣上下級關係明顯理清之後,使用ws的通信,會清晰明瞭的多,但是也會有很大問題是,大多數的系統都是理不清的,而且架構層次是不明瞭的,彼此之間的調用是伴隨業務發展不斷增加擴展的,這樣不管是xfire還是jax等,都會有一隻直接的後果,就是系統中,外部領域對象會越來越多,尤其是那些最上層的應用系統,要不斷的增加配置底層服務的返回對象等,除非是使用map的方式來保存數據。雙方需要嚴格約定key和value的類型,並且保證各種類型序列化不出問題。

這樣,服務端處理完成後,需要轉換domain爲map。從純實現方式上講,如果這個domain的字段太多,將是一個很容易出錯而且很體力活的工作。

然後高級一點,使用esb,同步或者異步,在payload中負載的業務信息也同樣存在相同的問題,要麼是領域對象,要麼是map的方式,同樣的問題。曾經本人就遇到過,消息的發送者payload中的對象變更了jar包,導致接收到的消息不斷報錯類型轉換錯誤。這其中的溝通成本太大,直接超出項目前期預算。尤其是系統架構很大的情況下,這種情況會很明顯。

 

如果使用json,那麼接口的返回業務值,只有一個string,而不會因爲服務器端升級領域模型改變導致所有的客戶端必須都升級。即便是服務器端升級,那麼返回值中只要保證key還是那些key就可以,具體的客戶端解析等不需要去關注,客戶端不需要的字段,也可以直接忽略。

更爲方便的 ,在大產品架構下,這種json的通信,在前段應用上,還有一個很大的優點,比如:

 

在大產品架構下,發展的方向很明顯就是控件的通用化,js/css等效果的模式化,比如 投票控件/ 評論控件/ 上傳控件 等等,這些控件都是直接可以配置到系統中通用的,比如使用freemarker可能只需要引用ftl然後加一個<@xxx/>宏就可以完成。其底層的調用等也是一些通用的ajax請求接口。

系統A -> B ,這樣的調用關係下,B返回一個json格式封裝一層,封裝成一個js的觸發器,也就是返回的結果是一個js串,可以直接執行調用js庫中的一個通用方法,來完成一個操作。比如評論完成後自動加載最新的評論列表等。

這樣對於調用者A而言,就不需要去做後續工作,如果這個工作由ws來完成,我們需要做的,首先得到返回值,然後將返回值渲染到視圖中,然後刷新視圖,自然的,這樣並不是一個通用控件該有的模式。

 

從本項目中json作爲數據交換格式的體驗來看,這種方式下的工作帶有很大的便利性,無論是開發階段還是測試階段,彼此之間解耦合各自分工互不影響,只要約定json數據中的結構即可。

 

參考資料:

http://www.json.org/json-zh.html

 

 

發佈了86 篇原創文章 · 獲贊 12 · 訪問量 59萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章