目前各类远程组件，真假三层组件等的大比拼,有人已经做好了一部分：http://www.winu.cn/htmls/714/114/(100)

提议做个目前各类远程组件，真假三层组件等的大比拼，为我们的开发提供一个好的选择，支持的顶。还没来得及做，有人已经做了(发布者 bluebird2ccc)：http://www.winu.cn/htmls/714/114/内容如下：－－－－－－－－－－－－－－－最近发现，国产delphi中间件越来越多，到处都是广告，都在说自己多好多好，本来这是件好事.有些人以此来与Asta,RemObjects，Midas等来对比，我感觉根本没的比，或许我的言论会让这些国产中间件的作者心理不平衡，稍安勿躁。你们都说是三层，请问，中间层可以扩展么，可以写逻辑么，不是较真，你们都没做到。只有QuickBurro可以支持该功能，这点很不错，只QuickBurro数据库功能不太人性化，不适合快速开发，希望其能在这方面改进。我已知的支持快速开发的国产中间件,不在列的大家可以补充(按我知道的时间先后顺序).1.DbAnyWhere 这个比较老了，,相信很多人都见过广告满天飞。基于ClientDataSet.2.MidAdo 广告做的也不错,现在在2ccc首页做广告。基于Ado.3.RemoteAdo 没怎么见广告，试用Midado过程中才知道。基于Ado.4.mateydb MateyDb需要RemObjects，MateyDb2封装了ClientDataSet.5.GreaterWare 一个新产品，基于什么技术没搞清楚，只知道支持Ado,bde,dbx.本文只挑选了与Ado兼容比较好的中间件来做测试。1.MidAdohttp://www.midado.cn版本：Release 2.4.3.0(2009.03.30)2.RemoteAdohttp://sites.google.com/site/remoteado版本：V 2.2.0.0(2009.04.21)3.GreaterWarehttp://www.greaterware.cn版本：Ver 1.0 Release(2009.4.18)测试环境.数据库:MSSQL2000,开发工具elphi7,操作系统:WindowXp, 商品资料表记录为8562条。耗时算法采用机器内部计时器的时钟频率，精度很高。测试程序源码和数据样本(ChaoShi.bak为MSSQL数据备份文件)可下载亲自测试，组件及服务端请从各自网站下载。本文意在指出各产品的不足,希望国产中间件更好的发展，仅代表个人意见，如果有对各位作者的得罪之处，深表歉意。测试指标:1.查询速度(20次不间断查询)--------MidAdo RemoteAdo GreaterWare第1次,耗时:372ms 第1次,耗时:183ms 第1次,耗时:180ms 第2次,耗时:221ms 第2次,耗时:161ms 第2次,耗时:87ms 第3次,耗时:217ms 第3次,耗时:159ms 第3次,耗时:86ms 第4次,耗时:221ms 第4次,耗时:163ms 第4次,耗时:84ms 第5次,耗时:219ms 第5次,耗时:165ms 第5次,耗时:85ms 第6次,耗时:219ms 第6次,耗时:166ms 第6次,耗时:85ms 第7次,耗时:217ms 第7次,耗时:166ms 第7次,耗时:84ms 第8次,耗时:219ms 第8次,耗时:162ms 第8次,耗时:84ms 第9次,耗时:220ms 第9次,耗时:163ms 第9次,耗时:84ms 第10次,耗时:219ms 第10次,耗时:158ms 第10次,耗时:86ms 第11次,耗时:217ms 第11次,耗时:157ms 第11次,耗时:85ms 第12次,耗时:219ms 第12次,耗时:166ms 第12次,耗时:85ms 第13次,耗时:219ms 第13次,耗时:162ms 第13次,耗时:84ms 第14次,耗时:221ms 第14次,耗时:157ms 第14次,耗时:85ms 第15次,耗时:221ms 第15次,耗时:160ms 第15次,耗时:87ms 第16次,耗时:218ms 第16次,耗时:161ms 第16次,耗时:85ms 第17次,耗时:218ms 第17次,耗时:166ms 第17次,耗时:85ms 第18次,耗时:218ms 第18次,耗时:159ms 第18次,耗时:85ms 第19次,耗时:221ms 第19次,耗时:159ms 第19次,耗时:84ms 第20次,耗时:216ms 第20次,耗时:157ms 第20次,耗时:85ms --------评析:查询速度来说GreaterWare速度最快,RemoteAdo次之，MidAdo表现不太理想。2.单条记录修改速度(20次不间断修改)--------MidAdo RemoteAdo GreaterWare第1次,耗时:309ms 第1次,耗时:227ms 第1次,耗时:6ms 第2次,耗时:311ms 第2次,耗时:201ms 第2次,耗时:5ms 第3次,耗时:309ms 第3次,耗时:194ms 第3次,耗时:6ms 第4次,耗时:313ms 第4次,耗时:196ms 第4次,耗时:6ms 第5次,耗时:316ms 第5次,耗时:199ms 第5次,耗时:5ms 第6次,耗时:317ms 第6次,耗时:205ms 第6次,耗时:5ms 第7次,耗时:311ms 第7次,耗时:191ms 第7次,耗时:5ms 第8次,耗时:316ms 第8次,耗时:206ms 第8次,耗时:5ms 第9次,耗时:314ms 第9次,耗时:201ms 第9次,耗时:5ms 第10次,耗时:313ms 第10次,耗时:197ms 第10次,耗时:5ms 第11次,耗时:312ms 第11次,耗时:197ms 第11次,耗时:5ms 第12次,耗时:319ms 第12次,耗时:197ms 第12次,耗时:5ms 第13次,耗时:314ms 第13次,耗时:190ms 第13次,耗时:5ms 第14次,耗时:311ms 第14次,耗时:195ms 第14次,耗时:6ms 第15次,耗时:309ms 第15次,耗时:197ms 第15次,耗时:5ms 第16次,耗时:316ms 第16次,耗时:190ms 第16次,耗时:5ms 第17次,耗时:313ms 第17次,耗时:190ms 第17次,耗时:5ms 第18次,耗时:311ms 第18次,耗时:189ms 第18次,耗时:5ms 第19次,耗时:310ms 第19次,耗时:190ms 第19次,耗时:5ms 第20次,耗时:312ms 第20次,耗时:190ms 第20次,耗时:5ms --------评析:修改速度来说,GreaterWare这方面优势非常明显（几乎不可思议），RemoteAdo次之，MidAdo表现不太理想。3.容错,断线恢复.（测试步骤:查询出数据后,将服务端停掉,修改DbGrid中的数据，提交）MidAdo: 提示 /"Socket Error #10051/",提示关闭后,当前的记录被修改，变为浏览模式(很费解,怎么恢复记录和再次提交呢),再次启动服务器,移动记录无任何提交反映，当前记录亦无法恢复。RemoteAdo:提示 /"Could not connect to RemoteAdoServer/"，提示关闭后,当前记录仍然为Edit模式,再次启动服务器，移动记录进行提交，提交成功。GreaterWare:提示 /"网络发生故障或服务器关闭,请等待恢复后再进行操作。/",提示关闭后,当前记录仍然为Edit模式,再次启动服务器，移动记录进行提交，提交成功。－－－－评析:这方面MidAdo做的差一些，不知道是何原因，RemoteAdo和GreaterWare均表现良好。4.改造难度MidAdo:需要替换连接组件,Query等数据操作控件RemoteAdo:需要替换连接组件,Query等数据操作控件GreaterWare:替换连接组件.－－－－评析:改造难度来说,GreaterWare最容易,而且最省工.MidAdo和RemoteAdo来说，差不多,MidAdo要好一点,因为RemoteAdo没有提供Table组件。5.内存,CPU消耗MidAdo: 20次不间断查询服务端(madosvc.exe)占用CPU峰值30%,内存占用11.628MRemoteAdo:20次不间断查询服务端(RemoteAdoServer.exe)占用CPU峰值32%,内存占用 11.156MGreaterWare:20次不间断查询服务端(GreaterWareServer.exe)占用CPU峰值16%,内存占用 8.116M－－－－评析:MidAdo和RemoteAdo接近，GreaterWare内存和CPU消耗很低。6.数据库支持MidAdo: 支持各种数据库RemoteAdo:支持各种数据库GreaterWare:只支持网络数据库，Access等桌面数据库无能力为。－－－－评析:MidAdo和RemoteAdo表现良好,GreaterWare这方面表现不好。后记：测试结果让我非常意外，原因在于一直以为MidAdo一定胜出，而事实确证明了它在各方面都还需要很大的提高。看来选用中间件还真是需要谨慎，看完广告，回家自己做个测试。同时，希望本文可以让各中间件作者可以看到自己的不足，借鉴对方的长处，来不断的提高和完善自己的产品，这才是我想看到的。

赞同

顶！！！！！

先做个海量数据查询比赛,在内网比赛吧，如果是外网，就是传输的问题，传输一般都是TCP，这个传输上区别不大，那就比较对大数据量的处理速度。

这个建议说的好,双手赞成

我也支持，下载GreaterWare先做个测试吧。www.GreaterWare.cn

测试我还没做，有人已经做了，看看这个：http://www.winu.cn/htmls/714/114/

个人机器不同，配置不同，这样的测试只是测试者自己有用。因为你缺少了一个最通用的比较。直接用自带的ado组件连接，所费时间。希望能提供ado直接连接的测试结果。

这这这，这都哪儿跟哪儿？列出的来的这些产品（其实也说不上来应该叫什么）、应该都是一些原型或半成品，和中间件根本不搭边（这么说，并不代表没有用处或不好），商品化程度都很低的。这里不是要引起概念或名词上的大争论，而是想说，这些离能够正儿八经卖给专业用户（最终应用型软件企业）进行应用软件开发的程度还差极其遥远！现在，已经不会以中间件的商品概念来向软件企业销售了，一般会叫做业务基础平台或业务架构平台，大体需要涵盖：基础运行引擎、数据库设计工具、界面设计工具、图表与报表工具、工作流设计与运行引擎、组织权限控制及定义工具、分发与打包、设计过程控制等，另外需要完整的理论体系、文档资料体系、培训和实施等等。我听说过的只有以下这些：金蝶BOS用友UAP金算盘起步X3（以前是思维加速的TIB)普元EOS金富瑞......就是我所说的这些，其实离商用也差得远了去了，除了 X3 是可以真正商用得，其余的全是本企业的开发人员在使用。中国的管理软件，号称南金蝶、北用友，不管真真假假、反正钱赚得算是多的，但是他们的 BOS、UAP 中间件平台自己的程序员能用转 30％就不错了。因此，我奉劝本文所列“产品”的开发者或拥有者，不要做商用的美梦了，思维加速公司从1998 年开始就替大家把梦做到现在了，聪明的是金蝶和用友，知道只有最终应用产品才是生财之道，什么财务、集团财务、ERP。中间件也罢、构件也罢、可复用的代码也罢，让自己的应用开发多快好省就好！

我一直觉得ASTA不错

的确楼主也只是测了速度这一关，并发性什么的并没测过，之前花大价钱买的一套RemoteADO在并发性测试方面，根本就不能过关，几个客户端一起执行查询，服务器马上当掉，其他几个没测试过，另外看看几个“产品”的部分代码也就MidADO写的还算规范，其他的说实话我都还看不上，这种东东称中间性的确是过了，算一套数据存取控件还差不多。

cpj7406说的比较靠谱。看了这个测试并下载用过之后，只有一个感觉：现在Delphi开发人员都这种水平？？？还是Delphi真的要退出历史舞台啦？？？有时候真的想静下心来写点三层或者多层的东西给大家扫扫盲。。。算了，不说啦。。。。郁闷。。。。对cpj7406的内容再补充一点吧：其实思维加速都是出来很晚的东西，比它更早的叫VDTools，不知道死掉没有。。。。

感谢bluebird2ccc和wobudong的劳动！

测了一下我自已写的数据访问组件，结果如下：环境：本机测试，基于TClientDataSet，传输层为kbmMW，传输中采用了压缩与加密。1.查询速度(20次不间断查询)第1次,耗时:1810ms第2次,耗时:1717ms第3次,耗时:1706ms第4次,耗时:1717ms第5次,耗时:1706ms第6次,耗时:1704ms第7次,耗时:1704ms第8次,耗时:1707ms第9次,耗时:1698ms第10次,耗时:1689ms第11次,耗时:1700ms第12次,耗时:1692ms第13次,耗时:1687ms第14次,耗时:1699ms第15次,耗时:1688ms第16次,耗时:1692ms第17次,耗时:1698ms第18次,耗时:1701ms第19次,耗时:1693ms第20次,耗时:1686ms2.单条记录修改速度(20次不间断修改)第1次,耗时:0ms第2次,耗时:0ms第3次,耗时:0ms第4次,耗时:0ms第5次,耗时:0ms第6次,耗时:0ms第7次,耗时:0ms第8次,耗时:0ms第9次,耗时:0ms第10次,耗时:0ms第11次,耗时:0ms第12次,耗时:0ms第13次,耗时:0ms第14次,耗时:0ms第15次,耗时:0ms第16次,耗时:0ms第17次,耗时:0ms第18次,耗时:0ms第19次,耗时:0ms第20次,耗时:0ms根据以上结果与其他三个产品相比“查询效率”还是比较低的，这也可能是基于TClientDataSet的通病，必须在服务端检索后最新打包，需多滚动一次数据集的结果，而RemoteADO与MidAdo则是直接的ADO数据流还原，GreaterWare未知。如要增强效率可能对kbmMW还要改造，其中间对流操作转了多次，而RemoteADO、MidAdo要相对原生一些，但对“修改效率”还是感到比较奇怪，我的多次尝次后的结果都是0ms，这性能好像无人能及。

考虑到与楼主机器的不同，我这边的midado的测试结果是：一、查询20次第1次,耗时:445ms第2次,耗时:394ms第3次,耗时:376ms第4次,耗时:411ms第5次,耗时:450ms第6次,耗时:381ms第7次,耗时:382ms第8次,耗时:401ms第9次,耗时:382ms第10次,耗时:377ms第11次,耗时:385ms第12次,耗时:382ms第13次,耗时:366ms第14次,耗时:389ms第15次,耗时:371ms第16次,耗时:371ms第17次,耗时:387ms第18次,耗时:378ms第19次,耗时:369ms第20次,耗时:376ms二、修改20次第1次,耗时:597ms第2次,耗时:551ms第3次,耗时:573ms第4次,耗时:560ms第5次,耗时:563ms第6次,耗时:569ms第7次,耗时:553ms第8次,耗时:565ms第9次,耗时:558ms第10次,耗时:552ms第11次,耗时:565ms第12次,耗时:562ms第13次,耗时:562ms第14次,耗时:580ms第15次,耗时:574ms第16次,耗时:547ms第17次,耗时:546ms第18次,耗时:557ms第19次,耗时:563ms第20次,耗时:572ms

VDTools? 台湾人搞的?http://203.208.37.104/translate_c?hl=zh-CN&sl=zh-TW&u=http://www.infolight.com/discuss/index.asp%3Fstatus%3Dopen%26I1401%3D9%26ClassID%3D11&prev=/search%3Fq%3Dvisual%2BVDTools%26hl%3Dzh-CN%26sa%3DG%26newwindow%3D1&usg=ALkJrhjP918kgcbDu44egh5tAbYlfDw4wQ

经过修改速度提高了一倍，原因是kbmmw的压缩算法速度太慢。20次连续查询：第1次,耗时:995ms第2次,耗时:878ms第3次,耗时:872ms第4次,耗时:888ms第5次,耗时:865ms第6次,耗时:879ms第7次,耗时:880ms第8次,耗时:895ms第9次,耗时:861ms第10次,耗时:870ms第11次,耗时:859ms第12次,耗时:863ms第13次,耗时:838ms第14次,耗时:875ms第15次,耗时:844ms第16次,耗时:866ms第17次,耗时:843ms第18次,耗时:857ms第19次,耗时:850ms第20次,耗时:836ms速度慢主要在打包与压缩上，其他都差不多，要进一步改进也就这两点了。

你测试的修改的不会是0ms吧，我直接用ado测试也不是0ms啊，你不是只是本地提交，没提交到数据库吧？[]

越吹越神，大家好好自己体会吧，现在托太多。用过Middle ADO System的人都比较清楚。这里提供用多线程源代码，模拟多个客户端并发访问，大家可以进行压力测试。如果有多台客户端机器，同时运行多线程模拟，效果更加真实。比如10台PC，每台运行100个客户端线程。模拟最真实的情况，1000笔左右的数据量是一个平均值。所谓在10万笔记录里面做修改提交，有谁这样做过？要修改一笔记录要先返回10万笔记录？脑袋进水了。 TClientThread = class(TThread) private FStopEvent: THandle; protected procedure Execute; override; public constructor Create; destructor Destroy; override; procedure Terminate; end;{ TClientThread }constructor TClientThread.Create;begin inherited Create(True); FStopEvent := CreateEvent(nil, True, False, nil);end;destructor TClientThread.Destroy;begin Terminate; WaitFor; CloseHandle(FStopEvent); inherited;end;procedure TClientThread.Execute;var Connection: TMADOConnection; Dataset: TMADODataset;begin CoInitialize(nil); Connection := TMADOConnection.Create(nil); //Connection.Host := ... 这里进行连接参数设置 Connection.Open; Dataset := TMADODataset.Create(Connection); Dataset.Connection := Connection; Dataset.CommandText := 'SELECT * FROM TableName'; //这里写SQL while not Terminated do try if WaitForSingleObject(FStopEvent, 1000) = WAIT_TIMEOUT then //这里时一秒执行一次 try Dataset.Active := True; finally Dataset.Active := False; end; except end; Connection.Free; CoUninitialize;end;procedure TClientThread.Terminate;begin inherited Terminate; SetEvent(FStopEvent);end;

有另外一个现象，很多原RemoteADO的用户，现在都改用Middle ADO了，这些人体会最深。RemoteADO测试结果比MiddleADO好？ 那没有必要大家都把RemoteADO换掉啊？有用过两套控件的人，可以站出来发点声音出来。客观给大家讲讲。免得满天飞舞都是“测试广告”。