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

也觉得Midas很麻烦。
很多人没有把两层的程序写好，就开始追捧多层。
个人认为现在比较好的两层结构（对于Delph5+ +Sql Server2000）：
1、多将业务操作写成存储过程。
2、客户端将业务代码与界面代码分离。写在不同的单元里或者不同的类里。
3、使用TClientDataset+DatasetProvider。利用其离线缓冲机制，嵌套表功能（其实觉得现在的ADO.NET很多都是抄袭TClientDataset）。
4、如果进行大多数Mis系统进行oop分析，在这个结构里可以简化地这么处理：
i)所有实体类都为TClientDataset，不继承，比如订单类type TOrder=TClientDataset。TClientDataset有足够的能力进行TOrder的属性读写，增删改功能，不用另定义新类（这后面有个TClientDataset+DatasetProvider+Ado一个体系支撑）。
ii)事务处理类需要自定义，比如仓库管理类，这个类处理实体之间的合作，实体的流程。绝大多数的存储过程都是被事务处理类所调用的。 比如审核入库单。
iii)字典类和辅助类。比如常用数据查找，还有常用的日志管理，用户管理等。
（纯属私人经验）

不过这些和即将到来的.net平台编程比起来可能落后了。

 
to mrzj：
各大DBMS确实都提供了缓冲池，减少了磁盘访问，从而提高了性能。
但你要注意的是DBMS提供的缓冲池是在哪个层次和以什么粒度提供的。DBMS能够提供的是记录还是对象？至于你说的非MS平台下数据库连接机制效率的低下我就只有笑一笑了，这个没什么好扯的。
我从来没有认为多层既出，两层死光光。两层门槛低，有其生命力。
 
to chenglh:
sql2000本身就有缓冲池、线程池,打开sql2000帮助，输入"缓冲池"、“线程池”三个字查找！
 
用二层模式，当有１０００个客户端同时连接服务器工作，那么在数据库服务器中就有１０００个并发线程！这样服务器还不会死机吗？！在B/S中，客户端每取完一次数据后就断开数据库连接，可在应用程序开发中连接一次服务器是非常慢的。
 
两层三层都可以做到你说的"客户端每取完一次数据后就断开数据库连接"
关键看你的水平。
越吵越无聊，结贴吧。
 
用二层模式，当有１０００个客户端同时连接服务器工作，那么在数据库服务器中就有１０００个并发线程！
------------------------------------
用多层，１０００个并发线程也不会消失。会出现在什么地方？中间服务器。这样中间
服务器也会死机的（要么给客户端返回个服务器忙的信息。谁忙？我，中间服务器，不是数据库服务器，忙。或者忙得没空去返回信息。）。
可以配置多个中间服务器。当然可以。但Sql Server也可以使用服务器群集技术，具有高度的可扩展性，
对Sql Server不了解，要是Sql Server也能给要求排队，或者返回个服务器忙的信息的话，
中间层真的不需要了。

仔细想想，2层多层的中心主题还是扩展性和安全性。
 
to yu_ting,
你去微软的网页查sql2000的性能，上面写着你讲的并发线程，sql2000支持2亿个,你才讲了1000个，才用了20万分之一的性能，怎么会死机呢？

然后你在查中间层所支持的并发线程数，有没有支持2亿个的!我想未必能找到支持2亿个并发线程的中间层产品,如果做到这点，就不叫中间层，而叫数据库了！
 
ORACLE数据库是有实例的，SQL SERVER从SQL200开始也有了实例。实例它们为每个SESSION分配一个进程（注意，是进程！！！）和其它资源（这个开销也非常大，要知道，现在的DBMS在缺省情况下是按第三级进行的事务隔离，一个未提交事务在一个SESSION里面就对DIRTY数据有一份拷贝）。从上面，就可以看出对DBMS来说，每个SESSION是多么的宝贵。2亿个是个什么概念！！！希望某些人看清楚了再说。

对待厂商对自己产品的宣传，要特别小心。
 
马上要给一个卷烟厂开发一套软件，我一直在想用什么结构做。继续听大家的意见。
 
to yu_ting：
02年，我们搞过一个全省的烟草项目，从最上游的主料辅料供应商管理一直到最下游的访销员。是基于WEBSPHERE的开发，光买IBM的软件和服务就花了超过1000万。

出方案肯定是要根据具体情况的，但大趋势是很明显的。
 
但大趋势是很明显的，但我对C/S结构你点怀疑。我去年做过一个农业税征收软件，用的是C/S结构，用DCOM加SocketConnection进行连接，服务器使用InterBASE数据库。死机现象非常明显。用的就是上述“李维”方式的三层。
 
比较不喜欢那种首先表现出对一些基本问题的一定程度的无知后，再特意表现出一幅高屋建瓴的姿态（"嗯，这个，大家说得很好嘛，继续..."）。
踏实厚实，研究的态度，分析的、尖锐的态度我喜欢。
忍不住，冒犯一下。
 
李维那套是典型的伪三层，还不如两层的好呢。
 
我们的论题好像应该明确一下，‘Delphi编程，SQL2000作为后台DBMS情形下，程序结构问题，究竟多层有什么好过2层之处’。
首先，界面逻辑与业务逻辑混在一团的传统2层，不便于系统维护与演进。
所以应该把界面逻辑与业务逻辑清晰的分离，
至于数据访问部分，2种处理，一种是象java做法，做一个数据访问层，业务层仅仅访问
数据层，而不是直接访问DBMS。
另外一种做法，就是省略数据访问层，业务层直接访问DBMS。
以上2种做法各有千秋。
个人觉得业务层直接访问DBMS在delphi中似乎更好。
注意，在这里没有所谓midas出现。
 
本人的经验是，在中小企业里，两层意思，三（多）层编程，所在的查询和少量更改在服务层，而部分计算在客户机进行，理由是这样：
1、更强扩展性。c/s和b/s混用，编程量减少。
2、实践表明，大量的数据处理就在那几台机中，其它的就是查询或少量更新。
3、现在的客户机能力非常强，充分使用了客户机的能力。
4、分布的最终目的：利用所有的资源，一台服务器处理很多事肯定会慢，我们很少有大型服务器，由多台客户机进行计算，这也可能是比较好的方法。
严格来说，选用哪种是根据项目来定，但我以为：要稳定，更快报地交出项目，合理的利用资源，更少的硬件投资，发挥更大的作用.
 
to mrzj:
我还忘了一点要说的，就是“钱”的问题。现在的好多的数据库软件（如SQL SERVER）都是安着接点来收费的，每增加一个接点就要多大几百块呢。如果是5个接点的SQL SERVER和25个接点的SQL SERVER好象要差一万多块吧（具体的RMB不太清楚，要根据代理商那里了），这样，如果你做出来，一个两层的数据库服务软件，就如你说的，数据库可以完成数据的处理，可是这样要比多买一太一般的（P4应用服务器）也要贵出来好多的钱吧。如果你用一个应用服务器来管理的话，那就不必花那么多的钱给数据库的厂家了。再有，如果客户段，超过25个接点的话，你还用两层的话，那你只能用SQL SERVER 注册CPU版的了，大约好象是20万，好象这个费用，就高的太离谱了吧。
-------也许你现在的客户段没有这么多，但有一天，真的那么多了，难道先让用户花20万来买一套SQL SERVER吗？别的钱还没有算呢？天啊，这样下来，可是个大工程了。（注意：在大一点的工程里可不要用D版的啊，这样我的一个朋友遇到过，还没有调试完，数据库服务器就被人给版走了！呵）
 
to 沙隆巴斯的主人:
你的观点我大部分都同意，我看我在这放面和你还是有一定的距离的，希望你发言能多说一点，不要点到为止，我可要想好长时间，才能认同的。
///////////////////////////////////////////////////////////
说说你以前说的吧：
///“或许大家都看了李维的那几本书，觉得3层就在中间放了个DATASET与PROVIDER，前端用个CLIENT DATASET就是三层了。这样的伪三层大概是大富翁里用得最多的吧。这样的三层确实还不如两层的简单清晰。
但真正的MT体系不是这样的。客户端没有任何的DATASET，没有任何的SQL语句，客户端根本不知道数据库是否存在。它只是通过GUI为用户提供一个与业务对象通讯的接口。”///
你的前一段说的有一定的道理，我看着好向是大多数开始开发三层数据结构的入门时用的，不过在实现快速，的开发三层的时候，这种伪三层的开发方式也有他的优点，比如：好设计，开发的快，还有就是可以解决我上面提到的“钱”的问提。 缺点当然是有的，最大的缺点应该是：移植性和可重复使用性了，吧。---个人观点，请指教。

你的第二个观点我感觉，正好他的优缺点是和第一个是相反的。
我现在开发了一个客户端完全没有数据库组件的程序，只不过是客户端与服务器端都在一台计算机上的小程序，不用什么网络通信，就可以连接上的那种。可是在我看来还是没有达到你提出的那种理论，好象还有一段差距。
再有就是如果我把 client/appserver/dbserver 分别放在三台计算机上的话，我对与他们之间如何通信还没有很好的理解，请指教。
 
各位高手，那么有谁能提供一个真正的三层结构的范例，让大家一起学习学习。
 
急切盼望中！
 
TO vcanddelphi：
关于你的第二问，我假设你的应用需求如下：有一些用户位置较为集中，需要进行复杂操作，称为A类用户；一些用户很分散，进行较简单的操作，称为B类用户。你为A类用户提供订制的客户端程序（一般的DELPHI程序）；为B类用户提供浏览器程序。假设你按照三层进行设计，那么你一般需要一个数据库，一个应用服务器程序（例如COM+的），一个WEB服务器。A类用户访问应用服务器；B类用户访问WEB服务器。应用服务器程序访问数据库。现在的问题是：WEB服务器访问数据库？还是访问应用服务器？
两种方法都可以，但WEB服务器访问应用服务器是个更好的方法（当然，这样的系统要更复杂些）。WEB服务器这时候是应用服务器的一个客户端，从应用服务器的角度看出去，它与A类用户的客户端没有任何区别。这样，业务逻辑仅存在于应用服务器中，WEB服务器只需要关注表现形式的问题了。
 
您必须登录或注册才可回复。

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
查看
539
xalion
X
S
[杂淡]关于鸿蒙操作系统的一些个人观点
回复
0
查看
913
swish
S
顶部