關於 DataSnap
http://my.oschina.net/u/582827/blog/324464
【活躍】[深圳]自在(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位而言，實測過程很穩定。