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 時發生的事情。

--- 未完待續 ---