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

 

 

你可能感兴趣的:(DataSnap)