關於 DataSnap

【活躍】[深圳]自在(1634421739) 0:04:57

這幾天以一個簡單項目結合開源數據庫MySQL實測了一下

    DataSnap Server 及 Multi-Device DataSnap Client

    的基本功能與性能，感受仍是很是不錯的。整個測試過程消除了以前我對DataSnap的一些錯誤認識，尤爲是對移動設備如何經過DataSnap中間件訪問企業數據庫(MySQL)的一些細節。在個人測試中，特地爲了避開REST以及WebBroker技術，緣由是XE的DataSnap技術框架一直在優化，而到了XE7仍然保留了單獨的DataSnap Server模型。（總共有三種：

DataSnap Server、

DataSnap REST Application、

DataSnap WebBroker Application）。

       以前網友們曾笑話我這樣的作法有違三層開發的原則，不過我想這是由於你們沒有深刻討論的緣由。在個人測試中，採用的第一種模型即DataSnap Server，

        數據傳輸走的仍然是輕量級交換格式：JSON。只是協議不是REST而已。對某些觀點而言，我稍顯過份的作法是在Server端自定義了一個方法：
function TDSServerModule_TEST.ChangeSQLString(Value: string): integer;
begin
  SQLDataSet_TEST.Active := False;
  SQLDataSet_TEST.CommandText := Value;
  SQLDataSet_TEST.Active := True;
  Result := SQLDataSet_TEST.RecordCount;
end;
而在客戶端則引用服務端Proxy出的方法：
function TDSServerModule_TESTClient.ChangeSQLString(Value: string): Integer;
begin
  if FChangeSQLStringCommand = nil then
  begin
    FChangeSQLStringCommand := FDBXConnection.CreateCommand;
    FChangeSQLStringCommand.CommandType := TDBXCommandTypes.DSServerMethod;
    FChangeSQLStringCommand.Text := 'TDSServerModule_TEST.ChangeSQLString';
    FChangeSQLStringCommand.Prepare;
  end;
  FChangeSQLStringCommand.Parameters[0].Value.SetWideString(Value);
  FChangeSQLStringCommand.ExecuteUpdate;
  Result := FChangeSQLStringCommand.Parameters[1].Value.GetInt32;
end;
這樣作的好處是開發人員能夠徹底再也不理解REST協議以及JSON數據格式（雖然實際通信數據包仍然是JSON），在移動客戶端並沒有實際的SQL Client，有的只是DataSnap Client（也就是SQLConnection的Driver屬性爲DataSnap）便可訪問到最終的企業數據庫了。
有人擔憂這樣的方式併發鏈接以及事務處理會混亂，但實際來看，DataSnap既然推出這樣的模型，早已經考慮到這些問題了。個人實際應用併發鏈接測試中並未發生不穩定或數據出錯的現象。

固然能夠把ChangeSQLString這個方法更優化一些，加一個參數，便可讓雙方的通信不只支持SQL Query，還能夠支持存儲過程調用了。

這樣移動客戶端的數據請求是很是方便的，例如：
TheSQLString := 'select * from tableA where ID>' + Edit1.text;
try
  aclient := TDSServerModule_TESTClient.Create(SQLConnection1.DBXConnection);
  aclient.ChangeSQLString(TheSQLString);
  aclient.Free;
  ClientDataSet1.Close;
  ClientDataSet1.Open;
except
  showmessage('系統出錯，請檢查網絡鏈接或從新運行程序。');
  SQLConnection1.Close;
  SQLConnection1.Open;
end;

固然，誠如網友們提出的很是明顯的缺陷，這樣的三層架構所有都得由Delphi XE來實現，並不兼容其它語言。而若是中間件作成REST/JSON Application，那就不一樣了。

在整個測試過程當中，發現要支持移動端的稍顯複雜的需求，LiveBinding基本上成了廢物（不管DBExpress仍是FireDAC）。緣由是它壓根就沒能爲移動端提供Query及存儲過程等特性的支持。

實際稍複雜的移動端應用場景，LiveBinding這玩意用處不大。

我測試了兩種模式：

1. VCL Form Server Application

2. VCL Win32 Service Application，

   未能測試64位的緣由是沒有找到libmysql.dll的64位驅動。就32位而言，實測過程很穩定。