关于 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位而言，实测过程很稳定。