K
KervenLee
Unregistered / Unconfirmed
GUEST, unregistred user!
我是三层的拥护者，
您正在使用一款已经过时的浏览器！部分功能不能正常使用。
请尝试升级或使用 其他浏览器。
请尝试升级或使用 其他浏览器。
C
ccponline
Unregistered / Unconfirmed
GUEST, unregistred user!
我用三层开发时，有时也发现其速度没有二层快！有时也死机。但时，不管二层还是三层，如用户的服务器的内存达不到SQL2000的要求，所有的都是假的，因为当查找所需数据是会出现假死机现象，让用户很会认为系统有问题！
至于用三还是二，我一般的是用二，不过现在在试用三在开发。
有时我也在想三层究竟好在什么地方？我也不知！
至于用三还是二，我一般的是用二，不过现在在试用三在开发。
有时我也在想三层究竟好在什么地方？我也不知！
H
hgc9806
Unregistered / Unconfirmed
GUEST, unregistred user!
我是新手，我也说几句。技术我还很差不敢多嘴，但是好像数据库支持同时连接的用户数越多，好像越贵的，够用实用最好，该用两层就用两层，该用三层就用三层
Q
QSmile
Unregistered / Unconfirmed
GUEST, unregistred user!
>>该用两层就用两层，该用三层就用三层
但问题是什么时间该用两层，什么时候该用三层？
但问题是什么时间该用两层，什么时候该用三层？
Z
zhanggeye
Unregistered / Unconfirmed
GUEST, unregistred user!
什么是假三层?所谓真正的MT只使用接口，哪么你是否知道DataSetProvider数据处理的实质是什么？
它依然是接口！只不过在客户端用大家习惯了的DataSet模式来封装数据。这种承上启下的技术，带来的效益是很明显的。自己采用自己的接口封装及传递数据和它又有什么两样？
在这个层面上，ClientDataSet和二层上的DataSet能相提并论吗？大家好象对三层客户端采用ClientDataSet深恶痛绝的样子，但我认为，批判一种技术，至少基于理解的程度上，而不是人云云。就如你在动物园内见到的狼，请不要用狗的标准去评论它，因为你没见过在荒野里真正的狼。
它依然是接口！只不过在客户端用大家习惯了的DataSet模式来封装数据。这种承上启下的技术，带来的效益是很明显的。自己采用自己的接口封装及传递数据和它又有什么两样？
在这个层面上，ClientDataSet和二层上的DataSet能相提并论吗？大家好象对三层客户端采用ClientDataSet深恶痛绝的样子，但我认为，批判一种技术，至少基于理解的程度上，而不是人云云。就如你在动物园内见到的狼，请不要用狗的标准去评论它，因为你没见过在荒野里真正的狼。
沙
沙隆巴斯的主人
Unregistered / Unconfirmed
GUEST, unregistred user!
to zhanggeye：
如果还是围绕着数据库（而不是业务对象）进行程序开发，多层体系的一半意义就已经失去了。
如果还是围绕着数据库（而不是业务对象）进行程序开发，多层体系的一半意义就已经失去了。
Z
zhanggeye
Unregistered / Unconfirmed
GUEST, unregistred user!
to 沙隆巴斯的主人:
采用DataSetProvider和ClientDataSet来开发就是围绕着数据库吗？
建议你看看李维的 ADO/MTS/COM+高级程序设计篇。
在业务对象内,DataSetProvider提供数据操作接口，完全符合三层体系的设计原则。DataSetProvider只是业务对象中数据接口部分，一个完整的业务对象还会包括其它接口和业务逻辑。把它们对立起来是完全没有道理的。
ClientDataSet只是向业务对象的接口取得和提交数据，并在客户端采用DataSet的模式来封装，这样客户端就可以依旧采用数敏控件来进行开发，对于大量的现有资源直接就可以在三层开发中应用，而原来两层的部分优势也得到保持。这本来就是delphi高效开发三层的优点所在。(当然，只能用DELPHI开发客户端才有这种优势.)
说李维的三层是假三层，是因为没有分清ClientDataSet的数据处理实质是接口,是中间层的业务对象，而不是原先的DataSet哪样面向操作数据库。
采用DataSetProvider和ClientDataSet来开发就是围绕着数据库吗？
建议你看看李维的 ADO/MTS/COM+高级程序设计篇。
在业务对象内,DataSetProvider提供数据操作接口，完全符合三层体系的设计原则。DataSetProvider只是业务对象中数据接口部分，一个完整的业务对象还会包括其它接口和业务逻辑。把它们对立起来是完全没有道理的。
ClientDataSet只是向业务对象的接口取得和提交数据，并在客户端采用DataSet的模式来封装，这样客户端就可以依旧采用数敏控件来进行开发，对于大量的现有资源直接就可以在三层开发中应用，而原来两层的部分优势也得到保持。这本来就是delphi高效开发三层的优点所在。(当然，只能用DELPHI开发客户端才有这种优势.)
说李维的三层是假三层，是因为没有分清ClientDataSet的数据处理实质是接口,是中间层的业务对象，而不是原先的DataSet哪样面向操作数据库。
L
liuxiangsoft
Unregistered / Unconfirmed
GUEST, unregistred user!
可見﹐李維出几本書都是他的心血﹐他不會將真理埋葬﹗但是李維那時只是d5﹐或許﹐現在d6和d7已達到了這種面向對象的華的手段﹗
L
liuxiangsoft
Unregistered / Unconfirmed
GUEST, unregistred user!
不過﹐我想沙隆巴斯的水平不可能會高過李維﹐但是為什么﹐在這里的李維會給大家說得 一文不值﹐可能我們是時代的進步帶動了﹐因為李維出的書還是2000年﹐現在已到2004﹐
沙
沙隆巴斯的主人
Unregistered / Unconfirmed
GUEST, unregistred user!
TO liuxiangsoft：
李維兄是BORLAND公司的人，在立场中立方面是有问题的。
TO zhanggeye：
毫无疑问，李維的三层也是三层，从计算机技术层面上讲，它与其他三层技术是完全一样的。但若用ClientDataSet来将数据以RECORDSET形式（关系的，而不是对象的）送到客户端，那么就失去了在中间层进行分层处理的意义了。
李維兄是BORLAND公司的人，在立场中立方面是有问题的。
TO zhanggeye：
毫无疑问，李維的三层也是三层，从计算机技术层面上讲，它与其他三层技术是完全一样的。但若用ClientDataSet来将数据以RECORDSET形式（关系的，而不是对象的）送到客户端，那么就失去了在中间层进行分层处理的意义了。
L
liuxiangsoft
Unregistered / Unconfirmed
GUEST, unregistred user!
to : 沙隆巴斯的主人﹕
眾所周知﹐你是dfw的高手﹐三層的尖子﹗我前不久為一個pooler的問題等你給個例子﹐可見你工作真的太忙﹐后來在proman的幫助下我總算搞清了﹐但有關線程和在三層用到事務的問題不知你能不能幫點忙。急切盼望﹗
chinalx8028@163.com
眾所周知﹐你是dfw的高手﹐三層的尖子﹗我前不久為一個pooler的問題等你給個例子﹐可見你工作真的太忙﹐后來在proman的幫助下我總算搞清了﹐但有關線程和在三層用到事務的問題不知你能不能幫點忙。急切盼望﹗
chinalx8028@163.com
I
infowain
Unregistered / Unconfirmed
GUEST, unregistred user!
to : 沙隆巴斯的主人
看了你的代码，只是对于connection和query进行了池化，并没有考虑任何的业务逻辑在内，这样的话，用COM+本身提供的池化机制不是更简单吗？
看了你的代码，只是对于connection和query进行了池化，并没有考虑任何的业务逻辑在内，这样的话，用COM+本身提供的池化机制不是更简单吗？
I
infowain
Unregistered / Unconfirmed
GUEST, unregistred user!
to mrzj:
ADO没有传说中的那么好，突出的问题是速度太慢了，我现在在做实时性要求很高的系统，用ODAC，速度比ADO有近10倍的提高，所以现在决定抛弃ADO了。
ADO是好东西，但是不明白为什么微软把ADO搞得那么慢。
ADO没有传说中的那么好，突出的问题是速度太慢了，我现在在做实时性要求很高的系统，用ODAC，速度比ADO有近10倍的提高，所以现在决定抛弃ADO了。
ADO是好东西，但是不明白为什么微软把ADO搞得那么慢。
P
proman
Unregistered / Unconfirmed
GUEST, unregistred user!
TO: zhanggeye,
所谓多层，按照众多的说法，无非是表现层，业务层。数据驱动层，数据库等，其中还可以
根据系统的实际情况加N多层。
从理想的情况下来说，我们希望的多层结构的表现层，也就是客户端，无论这个客户端是一
个智能客户端中还是在IE中，我们希望它它后面的业务层或其它层打交道时，不能涉及到数
据库中的结构。一旦涉及到数据库的结构，理想中的多层就会削弱。如果CLientDataSet传
的是数据库中的某张表，或是某个查询，毫无疑问，这样的多层是要打折扣的。
可是实际系统中，我们遇到的问题，我们是否有足够的人手来开发真正的多层系统，各个层
之间用完善接口进行联接。实际是很多系统没有足够的人手来进行这样的开发，那么取而代
之用ClientDataSet直接传递数据库中的表也就不足为奇了。虽然这样与多层的思想是不相同的。
但是在资源充分的情况下，我仍然建议大家尽可能的用接口将各个层之间划分清楚，这确实
程序发展的方向，也为写出质量更佳的程序打下了坚实的基础。
李维的书是没有问题的，他提出了一个利用较少的资源来快速开发一个三层结构的方法，这
确实是一个三层。但是也许他不是纯的三层的概念。可是他的开发代价确很小，我认为李
维是用这样的简单方法把大家引入多层的概念。可是如果大家仅仅停留在这里，那显然是
是只知道是什么，而不知道为什么。
我也是看李维的书学习三层的。
但是在我的三层的系统根本就没有用过DataProvider，当然由于资源有限，我也用了ClientDataSet传一些数据。
所以说大家不要在Provider的上面浪费太多的时间，不需要Provider仍然可以传数据。
我更建议不要用Provider，Provider纯是封装数据方法。
而不用Provider，你可以更侧重于封装业务功能，这可能更好吧。
看大家讨论了很长时间，我觉得争论的有点没有意义，真正的掌握多层系统的开发思想才是
最重要的，这一点，我想我们都是可以互相学习的。
所谓多层，按照众多的说法，无非是表现层，业务层。数据驱动层，数据库等，其中还可以
根据系统的实际情况加N多层。
从理想的情况下来说，我们希望的多层结构的表现层，也就是客户端，无论这个客户端是一
个智能客户端中还是在IE中，我们希望它它后面的业务层或其它层打交道时，不能涉及到数
据库中的结构。一旦涉及到数据库的结构，理想中的多层就会削弱。如果CLientDataSet传
的是数据库中的某张表，或是某个查询，毫无疑问，这样的多层是要打折扣的。
可是实际系统中，我们遇到的问题，我们是否有足够的人手来开发真正的多层系统，各个层
之间用完善接口进行联接。实际是很多系统没有足够的人手来进行这样的开发，那么取而代
之用ClientDataSet直接传递数据库中的表也就不足为奇了。虽然这样与多层的思想是不相同的。
但是在资源充分的情况下，我仍然建议大家尽可能的用接口将各个层之间划分清楚，这确实
程序发展的方向，也为写出质量更佳的程序打下了坚实的基础。
李维的书是没有问题的，他提出了一个利用较少的资源来快速开发一个三层结构的方法，这
确实是一个三层。但是也许他不是纯的三层的概念。可是他的开发代价确很小，我认为李
维是用这样的简单方法把大家引入多层的概念。可是如果大家仅仅停留在这里，那显然是
是只知道是什么，而不知道为什么。
我也是看李维的书学习三层的。
但是在我的三层的系统根本就没有用过DataProvider，当然由于资源有限，我也用了ClientDataSet传一些数据。
所以说大家不要在Provider的上面浪费太多的时间，不需要Provider仍然可以传数据。
我更建议不要用Provider，Provider纯是封装数据方法。
而不用Provider，你可以更侧重于封装业务功能，这可能更好吧。
看大家讨论了很长时间，我觉得争论的有点没有意义，真正的掌握多层系统的开发思想才是
最重要的，这一点，我想我们都是可以互相学习的。
Z
zhanggeye
Unregistered / Unconfirmed
GUEST, unregistred user!
to proman:
我很赞同你的看法，而我更认为，既然是一个delphi程序员，就要充分利用delphi的优势。最简单的一种情况，一个销售票据对象向客户端提供一个货品清单接口，自己采用数组封装的效率就远不如采用dataset来得好。midas是三层上一种高阶的开发机制，不用它当然也能写三层，但用了它则可以轻松的写出三层。DataSetProvider并不只是纯粹的封装数据，你完全可以在它上面封装业务规则。纯三层的理念有时只是一种理想状态，需求的变化及业务规则的变化往往会导致数据库结构的变化，这些变化有的最终通过接口反映到客房端，并不会因为你采用自己的接口客户端就不用改了。而采用DataSetProvider/ClientDataSet,这些变化更能直接的反映到客户端。退一步来说，采用自己的接口也可以用ClientDataSet的模式来封装数据,为客户端开发提供便利。
三层的开发模式灵活多样，更多的是要从需求出发，理论的东西不要死套硬用，就如你所说：”真正的掌握多层系统的开发思想才是最重要的“。
我也觉得这种争论没什么意义，一直也不参与，只是对大家后来的评论实在难以认同，随便说几句而以。你大可聊作一笑。
我很赞同你的看法，而我更认为，既然是一个delphi程序员，就要充分利用delphi的优势。最简单的一种情况，一个销售票据对象向客户端提供一个货品清单接口，自己采用数组封装的效率就远不如采用dataset来得好。midas是三层上一种高阶的开发机制，不用它当然也能写三层，但用了它则可以轻松的写出三层。DataSetProvider并不只是纯粹的封装数据，你完全可以在它上面封装业务规则。纯三层的理念有时只是一种理想状态，需求的变化及业务规则的变化往往会导致数据库结构的变化，这些变化有的最终通过接口反映到客房端，并不会因为你采用自己的接口客户端就不用改了。而采用DataSetProvider/ClientDataSet,这些变化更能直接的反映到客户端。退一步来说，采用自己的接口也可以用ClientDataSet的模式来封装数据,为客户端开发提供便利。
三层的开发模式灵活多样，更多的是要从需求出发，理论的东西不要死套硬用，就如你所说：”真正的掌握多层系统的开发思想才是最重要的“。
我也觉得这种争论没什么意义，一直也不参与，只是对大家后来的评论实在难以认同，随便说几句而以。你大可聊作一笑。
P
proman
Unregistered / Unconfirmed
GUEST, unregistred user!
补充一句，我认为Borland的三层技术中MIDAS的核心实际不是什么接口或是Provider
而是ClientDataSet中Data的数据封装，也就是如何封装一个数据集通过网络传输，它封装
的数据结构是不公开的，这也是Midas的核心技术。而MIDAS的是否收费就是根据这个数据
是否在网络上传输来决定的。
而是ClientDataSet中Data的数据封装，也就是如何封装一个数据集通过网络传输，它封装
的数据结构是不公开的，这也是Midas的核心技术。而MIDAS的是否收费就是根据这个数据
是否在网络上传输来决定的。
沙
沙隆巴斯的主人
Unregistered / Unconfirmed
GUEST, unregistred user!
看了proman先生的回复，我就发觉他已经把我想到的都说了，我没想到的也说了，呵呵。
to infowain：
我公开的代码只是两个基本的类的代码，其实还有操作员类（TOperator）和操作员池
（TOperatorPool）；用户（TUser）和（TUserPool）；价格（TPrice）和价格池
（TPricePool）等等。因为和具体业务相关，不大方便帖出来的。
我自己在用DELPHI做的开发中，是坚决不用任何的Provider，但还是用了ClientDataSet，那是为了出报表，很无奈——实在是不想再去设计一个RecordSet了；再说，报表本身的性质与一般的业务对象相比也是有很大不同的。
to infowain：
我公开的代码只是两个基本的类的代码，其实还有操作员类（TOperator）和操作员池
（TOperatorPool）；用户（TUser）和（TUserPool）；价格（TPrice）和价格池
（TPricePool）等等。因为和具体业务相关，不大方便帖出来的。
我自己在用DELPHI做的开发中，是坚决不用任何的Provider，但还是用了ClientDataSet，那是为了出报表，很无奈——实在是不想再去设计一个RecordSet了；再说，报表本身的性质与一般的业务对象相比也是有很大不同的。
Y
yangying_2000
Unregistered / Unconfirmed
GUEST, unregistred user!
没想到还有吵这个的,先说我的立场,我支持三层,另外还有些要说的
1.某些人认为两层比三层效率要高,这个不敢苟同,确实,少了一个中间层,对client来说好象要少处理很多东西,其实不然,client对数据存取的代码放到了应用服务器,一般来说应用服务器性能好,因此,对于单个的查询的响应时间上来说应该差不多.其实效率高低主要看服务器的处理方式上,假设100个client同时上线,对于C/S来说,数据库会开100个会话,对于多层来说,数据库只会开应用服务器所请求的对话,一般来说不会超过10个,而100个client就分别把自己的请求交给应用服务器,应用服务器对请求排队,在自己的10个会话中处理完毕后再把结果返回给client,也就是说在C/S下,当client没有任何请求的时候,这些会话是停在那不做任何处理的,必须等client发出请求该数据库会话才会得到利用,而实际情况是大部分client的数据请求并不频繁,因此造成了浪费,所以从这个角度来看三层要好些.
2.有些人觉得所谓的伪三层不好,我倒恰好觉得非常好,因为那是用来替代两层结构的必须品,以现在的DELPHI,如果说做两层结构,真的不如使用伪三层,道理很简单,开发的过程几乎没有区别,但是伪三层的client的维护要小很多,两层需要装数据库客户端,需要定义数据库客户端别名,如果用BDE则还要装BDE,如果使用ODBC则还要定义ODBC的别名,这些环节一旦有问题,整个客户端都不能用,而伪三层则只要有执行文件和MIDAS.DLL即可,如果你用ASTA来做伪三层,连动态库midas.dll都省了,拷过去就能用.因此伪三层可以说是替换两层结构的利器.相比伪三层,两层结构几乎可以说没有任何优势可言.
1.某些人认为两层比三层效率要高,这个不敢苟同,确实,少了一个中间层,对client来说好象要少处理很多东西,其实不然,client对数据存取的代码放到了应用服务器,一般来说应用服务器性能好,因此,对于单个的查询的响应时间上来说应该差不多.其实效率高低主要看服务器的处理方式上,假设100个client同时上线,对于C/S来说,数据库会开100个会话,对于多层来说,数据库只会开应用服务器所请求的对话,一般来说不会超过10个,而100个client就分别把自己的请求交给应用服务器,应用服务器对请求排队,在自己的10个会话中处理完毕后再把结果返回给client,也就是说在C/S下,当client没有任何请求的时候,这些会话是停在那不做任何处理的,必须等client发出请求该数据库会话才会得到利用,而实际情况是大部分client的数据请求并不频繁,因此造成了浪费,所以从这个角度来看三层要好些.
2.有些人觉得所谓的伪三层不好,我倒恰好觉得非常好,因为那是用来替代两层结构的必须品,以现在的DELPHI,如果说做两层结构,真的不如使用伪三层,道理很简单,开发的过程几乎没有区别,但是伪三层的client的维护要小很多,两层需要装数据库客户端,需要定义数据库客户端别名,如果用BDE则还要装BDE,如果使用ODBC则还要定义ODBC的别名,这些环节一旦有问题,整个客户端都不能用,而伪三层则只要有执行文件和MIDAS.DLL即可,如果你用ASTA来做伪三层,连动态库midas.dll都省了,拷过去就能用.因此伪三层可以说是替换两层结构的利器.相比伪三层,两层结构几乎可以说没有任何优势可言.
Z
zhanggeye
Unregistered / Unconfirmed
GUEST, unregistred user!
李维的书好不好，我不想评论，但只凭是否使用DataSetProvider/ClientDataSet来断定李维的三层是假三层是不能接受的。DataSetProvider/ClientDataSet是delphi独有的优势，如果不充分利用，使用delphi开发三层和使用其它语言开发基本没有什么不同。认为ClientDataSet 使用后台数据库透明化了其实是一个误解，ClientDataSet只是从一个接口中取得了数据，接口内部来源是不知道的，可能是一个表，也可能是一个视图，更合理的做法是封装了业务逻辑后的一个结果数据集。因为大家经常同一个人开发客户端和中间层，所以理所当然的知道哪个DataSetProvider来源于什么，中间做了什么业务逻辑。如果中间层不是你开发的，只是告诉你接口接供什么功能及数据，这些数据采用ClientDataSet格式封装，哪么你还能知道后台数据库是什么类型，它的表名是什么，它是直接从数据库取得还是中间层自己合成的。这些都是不可能知道的。客户端只要对ClientDataSet进行处理，实现界面逻辑就可以了。所不同的是，这时你完全可以使用数敏控件进行可视化设计。这有几种开发工具能做到？
还是proman说的哪句话：”真正的掌握多层系统的开发思想才是最重要的“。理论是死的，不能不切实际的照搬。比如在业务对象的粒度控制上，所谓“真三层”是要求分得细，分得清。如果是一个多用户高并发的应用。这是非常有优势的。但对于中小型应用，这些优势收益远不如开发及维护成本的支出。一个胖中间层可能是更好的选择。
说这么多，有点象在为李维辩护了。所以有必要点一下，本人菜鸟一个，跟李维一丁点也不认识。粗读了他几本书，仅此而以。
还是proman说的哪句话：”真正的掌握多层系统的开发思想才是最重要的“。理论是死的，不能不切实际的照搬。比如在业务对象的粒度控制上，所谓“真三层”是要求分得细，分得清。如果是一个多用户高并发的应用。这是非常有优势的。但对于中小型应用，这些优势收益远不如开发及维护成本的支出。一个胖中间层可能是更好的选择。
说这么多，有点象在为李维辩护了。所以有必要点一下，本人菜鸟一个，跟李维一丁点也不认识。粗读了他几本书，仅此而以。
A
aRichMan
Unregistered / Unconfirmed
GUEST, unregistred user!
高手论战，太精彩了。