| ccvcd
39839
|
2010/4/10 18:00:42 |
| 能否提供下 NewMidas序列化clientdataset的数据格式吗？ccvcd@sohu.com谢谢。 |
| hf20
37944
|
2009/7/10 17:09:04 |
你的 dimeSoap 能发一份给我吗？
我找了好久都没有找到delphi下的：dime
12822850@qq.com |
| xbj520jj
33682
|
2008/4/13 15:29:47 |
| 真是太佩服了 |
| zsl_ak
33568
|
2008/4/5 3:14:52 |
查了下ODAC的帮助,SAVETOXML也支持向STREAM保存数据,
但是使用TROBINMEMORYSTREAM后,这个东西是根据查询动作创建的,作为结果集输出,在GETDATASET中能否释放呐(意思是真正的业务数据能输出吗)?
还是要在REMOTEDATAMODULE中申请一个全局的TROBINMEMORYSTREAM,每个RDM实例创建时生成一个STREAM,销毁时释放掉.用户端的查询动作每次都清一下这个STREAM,把新的数据写进去.这样碎片比较多啊...
我的代码是这样:
function TBSDService.GetDataSet(const SParam: BSDParams): Binary;
var
rs:TROBinaryMemoryStream;
begin
rs:=TROBinaryMemoryStream.Create;
with orqry_GetDataset do
begin
Close;
SQL.Clear;
SQL.Add(GetSqlCMD(SParam.Func_ID));
open;
end;
orqry_getdataset.SaveToXML(rs);
result:=rs;
//这里应该 rs.free;吗?
end;
应该怎样比较好呐? |
| zsl_ak
33567
|
2008/4/5 2:55:08 |
hdcopy,tintin1943两位大虾,花了一个礼拜,总算是可以写出框架了.
我用的方法和两位学的:
接口只开放GETDATASET和EXECSQL,因为业务逻辑比较明确,定义了PARAMLIST,客户端确定FUNC_ID和业务参数,SERVER端根据指定的FUNC_ID把SQL抓出来,再根据业务参数去DB里面捞数据.
问题是ODAC的TORAQUERY只有SAVETOXML,如何弄成BINSTREAM的?可以指导一下吗? |
| penal
33035
|
2008/2/13 10:40:12 |
新版本在这里, 欢迎交流.
http://www.delphibbs.com/keylife/iblog_show.asp?xid=29769 |
| anson52
32886
|
2008/1/25 16:37:17 |
One of the most innovative works. Credit should be given for your simplicity
and uncomplicated connection.
My full support. keep it up. By the way when can you finish the procedure :
Dataset.Applyupdates. |
| wangpingdejiejie
32885
|
2008/1/25 15:56:21 |
| 占座，听课。 |
| shileizi
32883
|
2008/1/25 11:02:34 |
关注三层很久了，但是发现这方面的资料太少了，而且都是有关MIDAS方面的。
不知楼上的几位大大能否多分享一下这方面的开发经验。 |
| hdcopy
32873
|
2008/1/24 17:32:27 |
tintin1943 和我的做法类似，但有不同，
1、我没有使用ro的数据库相关的东西，只用了其连接功能，这样自己的可控性更高些，也只需要购买ro sdk就可以了。
2、同样不使用ado，不过我使用了odac连接oracle，自己做的数据库连接池，不过TQuery或TClientDataSet之类的是自己创建销毁的，这种开销还是可以接受的，实际用其他系统它们也会做这类操作的。关键是数据库连接一定要用池，用池不用考虑长短连接的问题。
3、改用indy10可以用10.1.5版本的，直接用10.0.76没成功，snapshot版本需要修改的地方更多和兼容性差很多了。
4、同样用接口，client没任何sql，不传递sql给server，不过我设计的server提供的接口多不少，2，30个吧，每种针对一个业务操作，这样可控度高，便于提供更好的sql处理速度，不过如果需要实现的业务方法太多，tintin1943的方法也很好。
tintin1943中有一条有很大启发，我返回的数据集是variant的（Tclientdataset的data），看来可以试试tintin1943转为Binary的方法。 |
| arvin
32872
|
2008/1/24 16:31:08 |
都说的这么热闹,既是重复造车,但总有车轮大小不一的情况吧?各位高手,能否将自己的作品呈献?我们可以比较一下忧点和不足嘛.不如请示一下站长,做一此题的专题如何?
期盼中... |
| tintin1943
32870
|
2008/1/24 15:10:16 |
一些补充说明：
LoginInfo是校验用户信息的记录类型，包含有，模块ID，用户帐号、客户端IP地址等相关信息，服务端如果想拒绝非法IP地址或非法身份验证，可作相关的安全验证。
更难可贵的是，RO提供了对象连接池功能。一个24*7的服务端，最怕内存泄露或内存碎片。三层其实最忌讳的是避免频繁创建和释放对象。有了对象连接池功能，一个可以节省数据库的Connection连接，二来，不需要频繁建立和释放TQuery或TClientDataSet之类数据库组件。
另外，还有一些啰嗦的体会：
1、尽量不要使用ADO。ADO支持SQL Server是最完美的，对Oracle支持不好。但ADO打开稍微大量的数据，明显比DBX、Sql direct慢的多。三层最终通过CDS来转换成流或XML，因此需要快速的数据集单向速度。Sql direct支持MSSQL、Oracle、FB是最完美的，其TSDDataBase根据不同的数据库需要配置一下。
2、RO默认安装的是indy9，indy9效率比较低，建议安装Indy10。
3、RO也支持负载均衡，但是软件方式的负载均衡。有钱的，最好用硬件负载均衡方式。比如，F5，有了他，支持500个并发以上绝对没有问题。
4、如果频繁连接远程数据库的，最好将其设置为长连接，提高查询效率。 |
| tintin1943
32868
|
2008/1/24 14:52:05 |
我早就抛弃传统Midas方式，不是太烦琐就是效率太低。
我也说说我的remobjects做三层方式。
1、服务端有一个ModuleSql表，专门存储Sql语句。传参数有几种：
:ParamName、:SubSql、:SubTable等方式。另外ModuleSql表有
参数类型化格式（参数名称、类型、大小、输入输出、默认值等等），
比如字符串的Params，我可以声明成字符串来解析TParams方式。
2、服务端根据:ParamName、:SubSql、:SubTable来替换Sql语句或解析参数，或ModuleSql表的参数声明来创建Tparams。
3、服务端采取高效的Binary做返回值。微乳的Olevariant是万能变量，但效率太低了。
4、客户端与服务端通讯方式是接口方式。客户端有一个ModuleID，对应服务端的ModuleSql表。客户端调用方式一般为：
OpenRemoteData(LoginInfo,['ParamName1','ParamName2'],[ParamValue1,ParamValue])。客户端不写一条SQL语句。
5、ClientDataSet最高效的，莫过于LoadFromStream。从服务端数据集返回的记录，打包成CDS的TStream，然后转换成RO特有的Binary类型。装载LoadFromStream，几乎是一瞬间。
6、我只用了三种接口方式，一个是OpenRemoteData，一个是EexcCommand，一个是执行存储过程（可支持返回数据集或执行命令的存储过程）。还有一些常用的函数，比如返回服务器时间，IP地址等。
最爱Ro的三层方式，因为她提供了delphi类似的基本类型，包括记录类型、数组类型、流等高效的参数类型，她还提供了可灵活的通讯组件方式（如果你不喜欢，可任意切换自己的高效三层方式，比如，Indy10、dxSock、IOCP、ICS等），更重要的，她易于调试、不用注册、接口不烦琐等。 |
| red_sheep
32852
|
2008/1/23 10:29:47 |
高手啊!为什么没有早点看到这个呢.
这几天我刚做完远程数据模块的封装,
也是做的物理上的伪三层,目的只是封装跨网的数据访问
不过没你这样的专业,只是简单的利用midas封装了个SQL的传递,记录集返回和连接校验
早知道有现成的,我就不费心思自己做了 |
| mstarsoft
32849
|
2008/1/22 20:01:31 |
| 再说一句 既然做了这个东西（基本是仿ASTA概念） 那么如果不实现数据流压缩 英特网上跑意义就不大 另外应该参考ASTA的办法 对 BLOB 等数据 进行专门的优化处理，不管怎么样，能搞出个东西，还是很不容易的。 |
| mstarsoft
32848
|
2008/1/22 19:54:52 |
| 高手 高手已经不多了 肯专心做研发更难得了，这个世界呀，唉 都是金钱惹的祸 ... ... |
| hdcopy
32830
|
2008/1/21 16:27:22 |
进到这里的都是有缘人，说说我对3层的做法吧。
1、使用了remobject做通讯。如果没买它，又担心版权，自己
做一个socket通讯＋参数解析就好，remobject的更多功能
我没有用。
2、server如果返回数据集就是普通的tclientdataset的data
3、client取数据集，只是显示，可以用数据敏感控件
4、client与server的请求一般只传递参数，sql在server生成，
这样业务逻辑就不会在client实现，改起来简单。还可以
利用oracle（我的db选择）的动态参数绑定，优化速度。
5、client从server取回的数据集完全只读，如果要修改，
带参数调用server的接口。server上的实现可能是一条
DML的sql，也可能是复杂的存储过程。反正就是client
上不考虑具体实现，只管调用接口就好。client负责提供
良好的人机界面。server负责业务实现（可能业务的实现
会延伸到db层）。 |
| webfly
32822
|
2008/1/21 9:07:26 |
| 感谢共享～ |
| lvbu
32816
|
2008/1/20 18:16:03 |
| 感觉Midas好象对数据库操作起来比较方便.对于远程函数呢.即然是三层,也不光是数据的操作吧.比如界面层调用登录方法,调用日志记录,用数据集感觉还是不方便.remobject可以通过XMLRPC或者SOAP实现函数的传递.如果能加上就不错了. |
| penal
32796
|
2008/1/19 16:47:35 |
| 我从小语文不过关，大家就别再说help.doc写得不错了，怪羞人的 |
