Translate

2015/02/13

DataSnap 有狀態( Stateful )開發研討

做為一個簡單易用的 DataSnap,就從萬年範例開始說明:

基於 COM 架構:
DataSnap COM-Base 設計架構


基於 RESTful 架構
DataSnap RESTful-Base 設計架構


咦?好像差不多?
因為實在太像了,所以好像沒什麼變化,坊間有提到 DataSnap 的書籍大都是這樣的寫法。

先來說說萬年範例在實作上有什麼好處:
1. 需要的 Table 或 Query 可以一口氣全丟到 TDataModule,在 Client 端只需要呼叫指定的 TDataSetProvider 即可。
2. 不論是 Server 或 Client 在設計資料存取上都非常簡單,可以全力專注開發 UI/UX 介面。

缺點是:
1. 當 Table 或 Query 變多時,Server 會堆積非常多的元件,久了會造成設計時的災難。
2. 多數 DataSet 被開啟時,Server 負載會非常沉重,頻寬也會被大量占用。
3. 不論是 COM-base 或 REST-base,Server 對於多 Client 的處理都是採 Blocking 模式,Stateful 設計下若有大量 Client 開開關關 DataSet,Server 上光是排隊處理資料載入就會更浪費系統資源。

Com-base DataSnap 在有狀態的設計下,還有 Client 異常斷線造成 Session 無法釋放的問題,除了坊間外,新的版本上也是利用「超時釋放」的方式來解決,雖然做得不漂亮,但至少是解決問題了。

REST-base DataSnap 在 Client 交握上就寫得比較好,幾乎沒有發現有 Session 卡在 Server 上的問題,明顯感受到 DataSnap 進步了。

REST-base 架構在 Server 端還可以在 TDSServerClass.LifeCycle 下設置 Session 行為,調整為 Invocation,立馬就將 Stateful 改變為 Statusless,REST DataSnap 穩定性將會提高。

REST-base 看起來是不錯的選擇,COM-base 可以靠邊站了嗎?

從當時的說明手冊來看,REST DataSnap 是最佳的選擇。

接下來會提到關於開發 REST DataSnap 時發生的事情。

--- 未完待續 ---

沒有留言:

張貼留言

Delphi 自動化 JSON 格式相容性分析

Delphi 自動化產出的 JSON 格式一直被詬病著,因為它的 JSON 格式在起始處一定會強制寫入「Meta Data」,它看起來像是: "table":[["EmpNo",6,0,0,0,4,0,0,false,false,...