Delphi 和 CB 的雲端技術，安全嗎？

在「都加密了，還怕什麼?」這篇有提到關於雲端技術常被探討的安全性議題。

可以知道

• 只要採用合適的加密法以及自訂的傳輸方式，可以使雲端應用更安全。
• 不是公開制定的協議，被駭客盯上的可能性機乎為零。

或許以 DataSnap 這種小眾市場上，稍加封裝就可以讓安全性大幅提升。

當然，Borland / EMBT 如果有開後門的話就另當別論了（笑）

REST DataSnap: Server Methods Lifecycle 的差別之處

REST DataSnap 的 Server methods Lifecycle 有：Session, Invocation, Server 三種選項。


Session:
每個 IP 只會固定配置一個實體，直到 Client 離線後釋放。


Invocation:
每次連線都會配置一個新的實體，到 Client 離線後釋放。


Server:
只有一個實體，給所有 Client 使用，類似 Com-based 的 Threading Model : Apartment




其它的教學連結：

Delphi Labs: DataSnap XE - Server Methods Lifecycle         

DelphiLabsDataSnapLifecyclePart1        

DelphiLabsDataSnapLifecyclePart2

DataSnap 製作 DB Connection Pool 的範例

ID: 28097, Sharing DB Connection in DataSnap with different Server Classes

例用泛型技巧來儲存 TSQLConnection。真是長見聞了！

※以 TDSServer DataSnap + Delphi XE 製作。

關於ClientDataSet.Filiter的Trim補充

Delphi in Depth: ClientDataSet 愛好者Cary Jensen在他的部落格上有回應我對Trim參數的問題。

寫得好詳盡，在這邊存個傳送門：Using Trim in ClientDataSet Filters

Firebird 版本選擇：Classic, SuperClassic, SuperServer

Firebird 官方說明文件：Classic, SuperClassic or Superserver?

Classic：

連線方式採 1 程序(Process)對應 1 連線，單一程序崩潰時並不影響其它連線。

SuperClassic、SuperServer：

• 採 1 程序對應所有連線，該程序如果崩潰即所有連線都會異常。
• 承上，崩潰後該程序會自動重啟。

資源分配上：

SuperServer ＞ SuperClassic ＞ Classic。
(※SuperServer 還多了一個作弊緩衝區)

只有 Classic 和 SuperClassic 能同時連線。

SuperServer 在 Windows 下預設只採用第一個認到的核心。必須到 firebird.conf 設定 CpuAffinityMask。

本機連線：

只有 Classic 和 SuperClassic 提供，有安全性的問題，但搭配單機版應用程式下非常實用。

三款都有各自的特色。
如果還是不知道要用哪個，就下載 SuperClassic 吧。


2015/05/06補充：
謝謝Delphi.KTOP的leveon大提供額外的資訊，還有附圖解說，十分詳盡。
傳送門：Firebird – SuperServer, ClassicServer or SuperClassic?

另外，據說Firebird 3.0之後這三者會合成一個，不知道正式版發行後是不是真的會成真，期待早日釋出。

FireDAC dbExpress 效能之戰，使用DataSnap

打從接觸dbExpress（以下簡稱DBX）開始，對於DBX能否應用在實戰當中存在非常大的疑問。

但是ADO和FireDAC是屬於2-Tier架構元件，要和DBX這種屬於單向唯讀的元件比較，由於立足點不同，所以直接比較是非常奇怪的事情。

也許使用While Loop測試比較也可以；但測試結果與其說是測元件效能，說是測試電腦硬體效能應該更為貼切。

While not Query.Eof do
begin
  Query.FieldByName(FieldName).AsString...
  Something code...
  Query.Next();
end;

這樣的應用，現實設計卻很少在我們的專案中出現。
那麼這樣的測試方法，存在有以下兩點問題：

原來DBX4 Driver可以這樣更新

因為DBX4之後，這框架就進入維護期，RAD Studio XE各版就是Bug的修正。

剛拿XE7的dbxmss.dll到XE的環境下測試，居然可以正常使用。

原本XE下的BUG也確實有得到修正，太讚了！

只是到了XE7，還是有些許異常需要想辦法繞，使用起來還是毛毛的。

整個DBX4專案才這麼大，這樣也出包

怎麼繞呢？就是原本在TSQLQuery下就可以做的調整，現在要移到TClientDataSet下來做才可以。

最後，證明3rd才是最優的解決方案！

Devart的Dbx driver for MSSQL 就完全沒有問題。讚！