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

to mrzj:
不要以为现在的计算机的工作能力提高了就可以解决速度问题。
假设，在程序中，一个客户段上有TTable控件48个，其他的不算，这样，每一个TTable可吃掉你的服务器的40K的空间那将是一个客户端吃掉约1。5M的空间。好多用户一起使用的话，可是一个不小的开销的。用Tquery虽然不会吃掉这么多的空间，但好多的客户端一起工作也是一个不小的数字呢。并且，数据库不是永远那么点儿的，在现实中，它的增长是一个可怕的数字，这样在加上好多的客户，看你的数据库服务器能运行多快？
如果是三层的话，可以用分布式来解决数据库服务器的压力，这样看是那一个快呢？
还有一个问题，就是在两层上你不能进行智能判断，着又增加了服务器的工作量。举个例子来说：
有一个公司的员工在11：00-12：00时都向一个饭店来定中午12：00的饭，你总不能每来一条就处理一条吧。我想二层的话，只能这样处理了。但三层的话，就可以在应用服务器中加以判断，比如要“米饭”的多少个人，等等，可以一次处理。
属于个人意见，有不同之处，请指教。
 
我目前一直使用2层开发，3层有关心，不想过多评论。现在主要心思花在JAVA上面。

TO KingPro:
"当进行升级和维护时，任务变得特别繁重，要对每一个客户端的软件进行相应的升级和维护。"
可以使用在线升级功能非常轻易地解决以上问题，我就已经实现了。
TO vcanddelphi：
" 一个客户段上有TTable控件48个"，这其实不是主要问题，通过编程技巧均可解决。
 
vb杀手：
你提到的客户端升级问题，现在的二层技术绝对要好过三层的，二层可以做到象微软公司的自动升级一样，大致的流程是，如果要对某一部分的客户端进行升级，开发者可以通过internet把要升级的文件发布到web服务器或ftp服务器，当客户端的用户一执行软件时，自动升级模块会自动的到网站上找新版本，如果有就问客户要不要升级。这样可以做到不用停止工作的升级，这在三层中是做不到的。

TO：vcanddelphi,
一个逻辑应用就对应一个Table控件的编程方法，不管是在三层还是在二可以说是不大好的设计方案。我们建立Table控件的个数，应该是在系统设计时看到底此系统有多少个并发逻辑应用，比如说有5个并发应用逻辑，那么我们就建5个Table控件。我为一个城市的连琐超市设计程序，也就不足十个并发应用，就是说我的datamodule里不到10个TDataSet。每个TDataset都在模块加载时才加载逻辑应用，当模块不用时释放以便下个应用模块使用。

说到超市了，我就不信三层做的出来(只用二台服务器)，一天全部分店的销售数据最少6千多万行，规模大些的分站一个满足条件的查询结果就有几百万行。如果二层一台服务器就可以做出来。

我做的这个超市项目，总部有五百多人，二层应用，速度很快，网站上供货商查询销售与库存，一个月的数据，56K的modem二秒内就可以见到前三十个结果。并发量我做的测试是可以支持一秒150个并发。另一点就是省硬件的钱，服务器只用了一台HP6000做为总部应用，还有一台做数据备份，当然每个分店都有一台没这么好的了。
 
支持二层结构...为什么就不说了.....

跨地域的使用就用b/s结构+离线版......效果比三层跨internet访问要好的多了......

所谓的业务逻辑是骗人的.......三层要修改业务逻辑和两层的又有什么不同..怎么修改法都是要修改......

不要吵这种问题了结贴吧,把所有的分合给我了.......
 
to mrzj and chnplzh:
大家别忘了，如过客户段都是同一个程序那还好一点。
如果客户段不是同一个程序但有一部分是相同的，但都是调用同一个数据中的东西，你的两层的方法，不是要写好多的重复代码吗，这不是有反“高质量代码编程”吗？
并且，客户段要升级，那不是更麻烦？
 
to vcanddelphi:
我想楼上所说的应该是另外一个概念吧！
如果客户端不是同一个软件，那按楼上所说的，好象中间层变得要脚踩两只船了，
甚至脚踩两只船以上。好象不对劲！
 
看了上面的帖子，简直不能让我相信，大富翁里的主流意见居然是认为在大、中型开发里2层更有优势！！！！

或许大家都看了李维的那几本书，觉得3层就在中间放了个DATASET与PROVIDER，前端用个CLIENT DATASET就是三层了。这样的伪三层大概是大富翁里用得最多的吧。这样的三层确实还不如两层的简单清晰。

但真正的MT体系不是这样的。客户端没有任何的DATASET，没有任何的SQL语句，客户端根本不知道数据库是否存在。它只是通过GUI为用户提供一个与业务对象通讯的接口。

应用服务器识别出不同客户端，可以确定允许它做什么和不允许它做什么（权限只有在服务器端实现才是可靠的，只靠在客户端通过变灰或隐藏菜单来保障权限那是不入门的初哥所为）。可以根据客户端的要求做各种事情（比如，开个户，客户端提供用户名称，电话等。。。，应用服务器去判断是否可以开户，开户成功就告诉客户端成功，否则通知失败，新开的用户对象可以缓存在对象池中，下次可以迅速调用，这比上数据库查效率高得多）。因为所有的资源、对象都由应用服务器控制，可以方便的进行对临界资源进行控制，而两层是难以做到的。MT在大型应用中的优势还多着呢，我实在不想赘述了。。。

大富翁里的问题是大部分人都被李维的那几本书误导了，以为三层就是那样的。否则，楼主的问题早就不是问题了。
 
to chnplzh：
客户端是什么根本不需要应用服务器来关心，只要客户端遵循应用服务器所定义的协议（COM+也好，SOAP也好，CORBA也好）。客户端可以是DELPHI编的WINDOWS上的图形界面程序，也可以是WEB SERVER，WEB SERVER调用应用服务器中提供的服务。而应用服务器只有一个，根本不存在脚踩几只船的问题。
 
关于多层和两层在性能上的比较，是不能够简单说两层就快过三层的。

当负载小的时候，两层有优势。但随着负载增加，多层的优势就开始体现了。当规模大于
某个隅值的时候，多层体系的性能就要好于两层。

而且从拓展性和可维护等软件工程中重要的方面去考察，多层都具有优势。这也是为什么
多层成为大潮流的原因。

 
to chnplzh:
前面“沙隆巴斯的主人”讲的很清楚了，并不是什么脚踏两只船，而是服务器应该作的。

to 沙隆巴斯的主人:
其实你说的也过于偏激了点，对于三层，我认为在小的程序上，用逻辑三层是一个比较好的想法，因为，开发起来快，又避免了两层的缺点。
不要以为三层的东西都是来做大项目的，小项目用三层，想开发的快，又要对以后的扩展有好处。用一些数据库的控件来进行通信，不是一个很好的办法吗？
难道非得用（com+ ,dcom等）通信才行吗？这样在小程序中，只会增加开发的工作量。
 
我沒做過二層, 98年以前做單層, 98年后一直做三層, 覺得三層比較靈活
 
现在只关心简单、方便。
客户不是专业，不会给你执行复杂的安装设置！[^]
 
TO 沙隆巴斯的主人:
您所说的涉及的范围太大，好象与楼主的话题不符。

顺带做个调查，大伙除了使用Delphi或C++Builder来开发三层项目，还使用什么别的
开发工具来开发？
 
to vcanddelphi：
你说的“逻辑三层”应该是个DO、BO、PO的设计模式吧，它们完全可以存在于同一个进程里面。这个模式应该来源于SMALLTALK的MVC（在UML中的分类非常接近于MVC，它认为对象有3类：实体对象、管理对象、边界对象）。应该说DO、BO、PO模型是MVC在数据库类应用中的一个具体化，而三层体系则是DO、BO、PO在分布式上的一个实现。
至于是否非得用（com+ ,dcom还有什么COBRA、J2EE、SOAP）等来实现？ 你完全可以自己来定义一套自己的RPC，我的同学在德塔斯曼就自己在SOCKET之上实现了自己的RPC。但这样做的效益如何就要另外考虑了。
 
不要吵这种问题了..结贴吧.
 
to 沙隆巴斯的主人

你讲的中间层有线程池，缓冲池，比较有名的中间层的软件确是能很好提供这些。但我我觉得你上了这些中间层软件商的当了，这些中间层软件做的在好，也不如直接用数据库好，只要你的数据库不是为多个应用提供服务的，你讲的这些sql2000数据库全都有。

在win2000下加sql2000，二层做的东西就肯定会比三层好，省时、省力、省钱、效率高！

你讲的概念大都是在unix或java开发上用的，因为这些产品没有一个很好连接数据库的机制(根本就没有象ado这样高效连接数据库的方法)，它们要靠中间层长连数据库(中间层一启动就霸占着数据库的连接)，这才是主要的，缓冲池这样的概念才是次要的。

就是因为有连接数据库性能不佳的原因后，才有了缓冲池什么的概念！
 
藏之....
 
Sql Server本身能够提供缓冲池功能。
是需要设置一下还是缺省提供,具体怎么操作不清楚。
 
根据需要和技术能力而定。
 
您必须登录或注册才可回复。

Similar threads

X
在datasnap 中使用unidac 访问数据（服务器端） - xalion
回复
0
查看
716
xalion
X
万
使用 IntraWeb (43) - 测试读取 SqLite (二) - 万一
回复
0
查看
412
万一
万
万
使用 IntraWeb (44) - 测试读取 SqLite (三) - 万一
回复
0
查看
381
万一
万
X
使用unidac 连接FB 3.0 （含嵌入版） - xalion
回复
0
查看
537
xalion
X
S
[杂淡]关于鸿蒙操作系统的一些个人观点
回复
0
查看
913
swish
S
顶部