标签:des io os ar for 数据 sp 问题 c
【活跃】[深圳]自在(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这玩意用处不大。
我测试了两种模式:
VCL Form Server Application
VCL Win32 Service Application,
未能测试64位的原因是没有找到libmysql.dll的64位驱动。就32位而言,实测过程很稳定。
标签:des io os ar for 数据 sp 问题 c
原文地址:http://my.oschina.net/u/582827/blog/324464