讨论：win2000+sql2000开发中大型系统到底是用二层好还是多层好！(100分)

TO 沙隆巴斯的主人
你好向理会错我的意思了，但同样感谢你的回答，我的另外一方面的问题的到了解决。
我是问。如果，在客户机子上不放任何数据库控件，的话，他与服务器的通信问题。
正如你所说的，如果应用程序服务器用COM+，那客户端（你说的A类的那种）该怎么和它建立通信呢？
1。如果客户端使用 DCOM或和他同等的控件 那可以和应用程序服务器可以建立通信，
可是提取数据是应该怎么设置呢？
2。如果不用 DCOM和它同等级的控件，那通信应该怎么实现呢？
谢谢！！！！
不知，你有没有QQ号，我想和你多学习。

to vcanddelphi：
原来是这样啊。你可以直接在客户端建立一个COM+的STUB，一般是如下形式：
var
aMyXXX: IMyXXX;
begin
aMyXXX := coMyXXX.CreateRemoteComObject('host_name');
....................
end;

我发现国外很多软件公司还在卖DOS的管理程序，这个不知道是算几层的。

两层还是三层讨论这么多了，到底还是没争论出个名堂。我觉的选用2层，还是3层，那要看你的应用的目标。需求不一样，两层和三层当然有区别。打个比方。你要给那些客户机数量比较少，分布集中的中小公司开发POS，ERP，MIS系统，那自然首选两层的C/S结构，但如果面向的是些大公司，他们的客户机数量多，分布广，并且商业逻辑规则复杂，出于易维护，易扩展，易分发的目的，你当然要选三层了。即便有些时候三层的C/S结构的运行速度慢，但权衡了分发，维护，扩展，钱等的利弊后，我门有时后还是要选择三层。两层的数据库程序做的是比较多的，技术也相对比较成熟，但我们中国人，尤其是一些软件公司，和客户，都有追捧新技术的毛病，社会上流行什么技术，就要什么技术，管她优劣与否，其实两层本身就可以解决问题的，但为了满足他们的虚荣心，做三层吧。

新鲜，2 层 3 层原来是速度的需要，听课。

经验：那个来钱快，做那个！

to 沙隆巴斯的主人
既然都是用COM+对COM+，那我在客户端用DCOM控件，其不是更简单？

to vcanddelphi：
当然可以用控件，也当然可以不用。但这些控件提供的的是标准的IAppServer接口，而不非你自己定义的接口。

to 沙隆巴斯的主人
1。你的意思是不是：用DCOM接收到的数据，没有自己定义的接口接收到的数据，好处
理？
2。你说的“ aMyXXX: IMyXXX;”我以前没有用过，可以说的在详细点吗？有没有着方面
的资料？谢谢！
再次感谢！

数据量越大，用户数越多，二层越快，认为三层会快的观点是错的！

慎用COM+或DCOM,不稳定的关键就在这里，用户数多、数据量大了的时候中间层会经常死机的！

COM+和DCOM微软都淘汰了，改成.net了，它的点缺点太多了，各位还觉得它好？要是90年代中后期谈这个还成，但是经过这么多年的实践，com和dcom的方式太不稳定了，慎用啊！小型应用还可以，大型的绝对不要搞com的形式，除非你的中间层服务器可以每天都重启运行！

数据量越大，用户数越多，二层就越快!

to vcanddelphi:
你可以在DELPHI的ONLINE HELP里查CreateRemoteComObject以及相关资料，你就会发现所谓DELPHI里的所谓COM控件是怎么回事了。

to mrzj：
如果我们做一个试验：比较使用两层技术开发的软件和使用三层技术开发的软件从数据库中取出相同数量的数据的速度。那么这个比较的结果是什么呢？一定是使用两层技术开发的软件的速度快。这个结论不论是从理论上还是实践上都是正确（增加的中间环节必然会产生负面影响）。但根据这点而推论出使用两层技术开发的软件比使用三层技术开发的软件在实际应用要快的结论，就缺乏依据了。因为在二层中，要访问数据就要访问数据库；而在三层中，设计合理的应用服务器可以提供缓冲池，可以大幅降低对数据库的访问。这时候二层因为结构简单而带来的访问数据库速度快的优势就被抵消了。这样，最终性能上谁优谁劣就与应用的特性，规模等一系列因素相关。但作为一般性的结论，随规模增大，三层在性能上具有优势。
与mrzj兄的讨论局限在性能上（速度），其实这只是在做系统架构设计时需要考虑的一个方面，此外还有灵活性、可扩展性、健壮性、经济性等一系列的方面考虑。 当把这些因素全部考虑进去，那么随着应用规模的增大，三层体系的优势将更大。
关于中间层会经常死机的问题，其症结出在程序设计不合理上。举个mrzj兄最爱提起的例子：SQL_Server2000数据库本身（这是MS的产品中比较经典的东西，MS为了因应反垄断压力，向部分国家开放了源代码，而我的老师在02年作为清华在数据库方面的代表访问了MS的数据库事业部，因此我也了解一些SQL2000内部的细节）。整个SQL2000的开发团队有500人，他们按照开发内容又分成次一级的团队，例如，某个组是负责语法分析器的开发的，另一个组是负责查询器的。那么语法分析器和查询器是如何结合的呢？他们之间的接口是如何定义的呢？各个组件的边界是由SQL2000的系统架构师划分的，其接口定义就是按照COM的格式进行的。也就是说，SQL2000本身就是一个由多个COM组件构成的整体。不知道mrzj兄是否也觉得它不稳定，经常死机。
其实，MS的东西几乎全部都是按照COM规范提供的，比如OFFICE系列（所以我们可以在DELPHI创建它们的自动化对象）、IE（QQ的那个什么浏览器就是在IE外面加了个套）等等等等。学过VC的人都知道MFC这东西，它是MS推出的一套商业化产品，但据我了解到的情况，MS内部是根本不用MFC的（MFC是给外人用的业余架构产品），他们的程序是用C++按照COM规范写的（现在流传出来了部分的MS源码，大家可以看看是不是这样！）。
没错，现在MS主推.Net，那么.Net与COM（COM+等）是什么关系？其根本性改进在哪里？也就是“自描述”！！！这是.Net最革命性的进步。（但还是晚了JAVA许多，JAVA一早就实现了自描述，这是JAVA对C++的最大的进步。自描述被认为是近10年在软件工业化上取得的最大的成就，它是组件技术的重要一环，相比之下OO技术都没它重要）因此，可以看出.Net并不是推翻了COM，而是更进了一步，适用与COM的依然适用于.Net。

to 沙隆巴斯的主人
你提到com开发，微软做出来的确是非常的稳定的，我指的是用开发工具delphi开发的com组件开发出的中间层产品来操作数据库是不稳定的。

你提到中间层的线程池、缓冲池等，我认为数据的线程池和缓冲池比中间层提供的要好！

你提到的“设计合理的应用服务器可以提供缓冲池”这点用delphi提供的mts等技术开发出的中间层产品是根本就做不到的！weblogic,webshare等中间层产品是有这些功能，但使用这些中间层产品，用delphi开发客户端的人更是少而又少。

多层的技术，不大适合在微软平台上使用。多层是为unix平台用的!三层在微软平台上用，就如二层在unix平台上用一样！

to mrzj：
》》我指的是用开发工具delphi开发的com组件开发出的中间层产品来操作数据库是不稳定的。》》对于这句话可以有两种理解：1、BORLAND的产品DELPHI对COM的支持不好，用它是无法开发出合格的操作数据库的软件产品；2、开发人员掌握不了用DELPHI开发基于COM的操作数据库的软件的技术。我想以上两种说法，BORLAND公司不会同意第一种；广大的DELPHI开发人员不会同意第二种。
》》我认为数据的线程池和缓冲池比中间层提供的要好》》DBMS提供了缓冲技术支持，而且现在各厂商的产品都做得很好。但这种支持是在数据库层次上提供的，是细粒度的（一般来说是这样，大部分的DBMS是关系型的，因此其提供的缓冲也是关系元组——记录行这一级的；ORACLE8i既以上虽然支持对象型数据库，但由于对象型数据库的不成熟，可以不于考虑）。而在面向对象的软件中，我们操作的是对象。为此，各中间件厂商在其产品中都提供了各种容器，用来提供对象缓冲支持。从上面的论述，mrzj兄应该可以明白：即使有了DBMS的缓冲支持，如果在中间层继续使用缓冲技术，依然可以使系统性能取得巨大提升。而从实际效果来看，这种性能的提升的效果远大于由于增加了一层中间环节而带来的负面影响（当然，这还是与规模大小以及应用的特性有关）。

》》“设计合理的应用服务器可以提供缓冲池”这点用delphi提供的mts等技术开发出的中间层产品是根本就做不到的！》》这就奇怪了，我自己手上的软件是怎么实现缓冲池的呢？
有兴趣的可以参见：http://www.delphibbs.com/delphibbs/dispq.asp?lid=2463683

》》多层的技术，不大适合在微软平台上使用》》得出这个结论不知道你有什么依据？若是真的，MS的.Net项目就应该马上流产，不用再搞了；COM+也应该从NT5.x里面清除掉了。还是举SQL2000的例子，mrzj兄应该知道SQL2000是可以通过发布/订阅模式来进行分布式数据库集群的，那么，你知道它的发布/订阅是用的什么技术吗？就是COM+！！！！

支持mrzj，我正用二层做着一个大点的系统呢，速度飞快。
理论归理论，实践归实践

to沙隆巴斯的主人：
Office,Sql Server使用Com技术集成似乎与中间层和本主题无关吧？

to chenglh：
Com与中间层确实是两个概念。我提出这个只是用来驳斥某些认为COM本身是不稳定的一种技术的观点。
COM是种优秀的编程规范，用它可以写出非常好的程序，包括多层体系的程序。

不上internet没有防火墙的话就二层的吧。其实无所谓。两层的话也可以做到很模块化的设计。三层的优势主要是架构上的。其他的方面也没什么特别大的优势。
p.s.
用不着考虑太多。其实，只要应用上够用就行了。如果短期内（二年内）客户并没有INet上的需求就大可不必考虑这么多。二层就二层呗。追概念没用的。易用，够用，好用就行了。

总的来说是二层，但细分了就多层了

看客户如何选择，如果客户觉得三层吹起来比较大则用三层，如果客户觉得二层省钱则用二层。如果客户无所谓则选择简单的二层。

建议三层，不要学李维的伪三层。
我想问下 沙隆巴斯的主人
在数据访问层中，1。你使用datamodel还是removete datamodel
2。需要多个datamodel吗？比如user类使用一个，shopping类再使用一
3。每个datamodel中都使用一adoconnection，下面带n多个adoquery？