記工做中關於webservice上層業務框架的思考

    由於業務中有增長對外的接口考慮用webservice實現，定義了一套加解密格式規範，而後就是作一個簡單的對業務邏輯的封裝代碼。

這個封裝代碼不能處理的有三塊內容：外部系統的傳入的數據定義，內部系統輸出的數據定義，業務邏輯處理代碼。

你們都默認承認的實現是由一個統一的對外函數參數和返回都是符合必定規範的xml

分歧出在了統一接口傳送到內部業務代碼的數據怎麼封裝上。

數據傳送格式：

因爲項目組中負責開發這塊的對xstream比較熟悉，天然得選擇了實體類封裝數據，由父類封裝通用數據，子類繼承由開發人員本身定義。可是業務接口增多的狀況下會有大量的冗餘實體類，因此他提出了用map封裝全部數據。另外一位同事提出了傳json格式給業務代碼。突然發現任何數據封裝都是能夠實現邏輯的，即便是xml字符串直接傳給業務代碼，只需提供統一的相似map的get和set方法，或者是xml上面封裝一個數據類，由xml字符串作爲數據的存儲格式，下面提供get ，set和其餘通用方法,並且這麼作有個很大的好處就是極強的靈活性，畢竟業務代碼是直接操做生成的xml的，缺點顯然是效率問題，每次都是字符串xml的解析，不過話說回來用webservice原本就不是什麼會考慮效率的業務需求，固然靈活性自己也會帶來另外的問題。

概括了下有如下幾種實現方案：

1.map封裝數據     

優勢：高效，靈活

缺點：沒有實體類那麼清晰的字段定義，不過對外系統通常會有詳細的格式文檔，這應該不是缺點

2.實體類封裝數據  

優勢：高效，結構清晰

缺點：會產生大量的冗餘類，對於某些業務需求這應該不是問題，通常系統都會有對應表的實體類，若是業務需求上沒有不少複雜的數據請求，是不會有太多冗餘類的，並且這自己也能夠有一些優化方案，好比某些數據在一個實體上的臨時存儲，不過對外系統有些不合適。或者創建有必定通用性的實體類。還能夠在業務代碼上再加一層工廠類作業務代碼處理組裝，在某些業務環境下會比較不錯。

3.xml字符串封裝類

優勢：靈活

缺點：低效，並且把框架層的錯誤整到了業務代碼中。

4.json等其餘數據格式

//TODO

忽然發現數據格式的定義對於一個框架是如此的重要，作習慣了JAVA的業務代碼，對於數據格式的考量愈來愈少。想到效率又想到這種業務用webservice這種技術是否合適的問題。反正是xml格式的文本，任何協議交互下均可以解決這個需求了，用webservice的好處又是什麼呢？？？

//TODO