讨论，关于三层，希望DFW的前辈们能参与，给大家上上课 (大家畅所欲言吧) (200分)

我也想了解解!
 
三層﹐速度太它媽的慢了。一點都不成熟。
 
to hiyaolee
三层真的不成熟吗？
 
ntugn说的“界面、业务逻辑的分离”的问题，我也想过，总觉得与三层有相似之处，不过一个是程序内部，另一个是通过网络，不知道想法对不对？
 
做标记
 
~~~~~~~~~~~~~~~~~~~~~gz中
 
新手上线，为避免两天的禁闭期，借贵方宝地一用，提提问题。
关于多层提交的若干问题。
1、在TClientDataSet中的Data和Delta中包含了什么信息，在TDataSetProvider.ApplyUpdates中的参数data就是Delta，在此Delta中的那些信息会影响最终的提交？ProviderFlags的信息包含在data、delta中么？主键的信息包含在Delta中么？
2、主键的信息保存在那里？如何取得？如何设置？
3、ProviderFlags中的pfinkey和主键有何关系？
4、upWhereAll、upWhereKeyOnly upWhereChanged三种方式提交的优劣比较？
 
楼上的，自己买本 delphi5(6)开发人员指南 看吧，这里是讲不清楚的
这本书有你所有疑问的答案
 
那就直接问吧：
我设置的表TableA的主键字段为联合主键，主键为TableA.Field1+TableB.FieldB，但在实际应用时，发现主键信息（IndexFields中）为TableB.FieldB，不知原因为何？请指教。
以上数据库为SQL Server 2000
 
baosoft@tom.com
我要例子哦！呵呵
学习各位DFW的知识，我的作用是提前帖子，哈哈哈
我是菜鸟，我发言了！哈哈哈
MSN：tonsonJ@hotmail.com
 
业务逻辑层：当然应该写在AppServer上。如校验数据的合法性，我认为客户端只是一个数据录入与显示，当然、因为明知道客户端的数据没法通过应用服务的逻辑校验而多次调用业务逻辑，增加了网络负担。客户端也得有一定的逻辑校验。
大家知道：三层的目的是为了减少客户端与数据库服务器交互的频繁次数（减少网络流量），不把数据库服务器直接暴露给客户端（增加安全性）。
其实，三层的真正用意：能否在广域上应用；能否为其它的应用提供集成服务。
因此，我认为：应用服务器开发不能限制只为自己客户端服务的目的出发，而应该多考虑系统是否有必要为别人的系统提供服务，减少重复建设发的代价！
由以上出发：我们应该遵循并制定一个不限制开发工具的标准，让大家的系统部署到企业的应用服务上，有一个很好的集成。你的业务应用层，能给别人一个服务的机会。
Web Service 不就是一个很好的标准！
Web Service开发，各个开发工具提供的方案不一样。还有我们的以往开发工具又不支持这种开发。
我认为：开发Web Service成为必然！
本人有一方案，就是为了能够提供这种需要，只要支持COM+的开发工具，都能做成Web Service的应用服务开发。只要支持COM调用的开发工具，都能调用你的业务服务。同时降低开发技术风险难度。

 
呵呵，速度是一直困绕3层的问题。
好的分析，好的设计，好的业务逻辑处理都能提高速度。
但对于网络状况不是很好的中国市场，3层只是花瓶模式。(中国的网络想对其他的一些国家已经算发达了。)
如何有效的处理这些方面的处理逻辑也是我们必须考虑和值得探讨的。
首先要知道你自己调试代码时都是在本机，也就是说3层的存在没有意义了。
所以我个人意见第一就是远程调试，直到让你自己对3层都死心为止或者尽量优化代码到在486下都能如在本机运行一样。
其次的是，对于3层数据模块的选择问题上。
不同的数据模块所能产生的效果，也就是说通讯的范围问题。
上次看到一个帖子说要通过dcom来进行广域网通信，呵呵，我并不是说这种行为不好，只能说在为客户实现功能的同时要增加你自己的实用性和可行性，虽然你研究dcom，通过几年甚至几时年的努力来达到你所需要的结果，不过难道不觉得舍本逐末么。
再接着就是业务逻辑问题了
没必要解释了，这个是除了上面的硬件基础后的最重要的软件开发核心了。
其实有很多人误解了以为业务逻辑只是存在于中间层内，只是如何用appserver调用和得到良好的结果集的问题。
在这个程序开始写代码前的分析设计中就必须考虑到这个问题了。界面是什么，代码又是什么，业务逻辑是什么，实现又是什么。
barton的话：关于业务逻辑，我习惯分成两个，面向持久的业务层和面向UI的业务层。要最终使客户端与服务器最小的通信量，建议你采用“业务语言”，因为大多数内容可以通过“业务语言”的约定解决。持久就是连接的数据库；UI就是客户端界面，包括Form，报表，Web页面，等等。“业务语言”是一种解决层间会话问题的约定集，例如，发送1表示要登录，发送2表示我要退出，等等。连接后服务端只报告已更新的部分，未更新的部分从本地策略中取。
ClientDataSet是一个集，你的服务器端如何操作，你的ClientDataSet得到的就是什么，这个是个人理解，也许有点肤浅，还请其他高手指教。
安全问题：不用考虑，因为即使不安全也不是你能改变做到的。
比如：Web连接时，通过80端口，呵呵，你怕Web连接传输不安全，你可以封它，那么你的网络存在也就没有意义了。
数据统一问题：若是你觉得非常有必要的话，那么实现也不是很难，加一个字段，调用这个记录时这个字段为1，退出变为0，如果是1，则其他用户不能调用。这个是个蠢办法，因为我还没有找到其他合适的方法，还请其他高手指教。
大数据传输可以先在本地打包，然后一起applyupdate到服务器。
先讲这么多，挂在着，等待提议和讨论~！
 
一般,‘阿西喊佛’参与的帖子都是三个代表的帖子！
绝对关注。
 
to 阿西喊佛：
你说的大数据传输可以先在本地打包，然后一起applyupdate到服务器。我是这样做的
当用户退出当前操作的界面的时候，再一起applyupdate到服务器，可是这样如果是碰到
大数据量的时候，就会很慢，而且有可能因为某中因素，没有更新成功，那么如何做才
能保存在本地，下一次运行程序的时候再次更新呢？谢谢，能不能说说
 
TO zzjmail
呵呵，这样的方法总比你每次都从服务器更新好吧，你想想，一次打包，然后更新，只跟服务器通信一次，你n次更新就需要n次的时间，呵呵，你算算怎么划的来呀。
如果要实现你说的保存在本地，那么可以用个临时数据集来保存你的data，当客户打开的时候把这个界面所对应的ClientDataSet.Data := 刚才你保存的那个临时数据集的data，这就实现了你所谓的打开时的更新，但是applyupdate是必要的，所以速度也是自然会降下来的。
远程不象本机操作，需要考虑网络因素，哎，头疼呀。
非人为的因素导致更新失败是肯定有的事，但是应当尽量避免。
又先说这么点了。
 
其实三层搞好了不慢，一下随便分析一下慢的原因：
1、错误的使用了数据访问层组件： 比如ADO 的那一套组件设置问题。
2、网络传输了不必要的信息包： 比如你知识更新一条纪录，却把所有的信息都传会服 务器
3、网络协议配置、硬件配置等的影响。
4、程序本身其他方面的健壮性。
 
我在最近也作了一个系统较大的系统，也三层的，在应用服务程序下做很大的工功，主要把程序写在CLIENT上面，系统现在可以正常运行，可是像前面所说，就是速度慢了一点，还有那个IIS有时出（500）的错，可把我给烦了，有没有那仁兄知道这个问题的解决的办法？
 
不要动之以"企业逻辑"这样的词来吓人,简单来说,三层三大的好处,也是外行人可以看到的
client安装简单, (维护起来爽多了,不用把数据库Client到处装了)
client看不到DBServer,(这样不怕有些吃饱没事干的人,乱动DBServer了)
节省DBServer的连线数(这可是省钱的地方阿,10用户的SQLServer就几十K RMB了)
 
ntugn
能邮一份给我吗？Liuren_flf@163.com
 
您必须登录或注册才可回复。

Similar threads

不
Delphi的参数传递约定以及动态参数个数(转载笔记) - 不得闲
回复
0
查看
701
不得闲
不
不
ISO8583报文协议（转） - 不得闲
回复
0
查看
670
不得闲
不
S
[转]ClientDataSet加上TDataSetProvider的数据保存问题
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
S
[原]Delphi2010中DataSnap高级技术(7)—TDSServerClass中Lifecycle生命周期三种属性说明
回复
0
查看
834
SUNSTONE的Delphi笔记
S
S
[转]ClientDataSet加上TDataSetProvider的数据保存问题
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
顶部