关于 DataSnap

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

这几天以一个简单项目结合开源数据库MySQL实测了一下sql

    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,ide

        数据传输走的仍然是轻量级交换格式: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位而言,实测过程很稳定。

相关文章
相关标签/搜索