开发了几年的delphi程序，手里的大型MIS系统有几个，但都是c/s。
准备将c/s转换为b/s，对三层结构的实施心有疑问。1 c/s型大量数据传递通过局域网，速度和稳定性有保证，三层结构中的传递是通 过互联网，大量的数据据流动不是很现实。
原有的较方便的操作方法在三层中会有一定的问题。
如 infopower中的数据下拉列表lookupcombbox,中c/s可直接将部分数据字典表连到控件中，三层结构就不能采用类似这样的方法，数据量太大，往往一个窗口中，下拉列表有很多个。现在三层中都是远程得到一个表的数据，再写入下拉列表，客户端的响应时间就比较长（一个大字典表，有几万条记录）2 b/s三层中峰值流量会造成服务端程序不稳定，许多大型结构中，连接超50后，服务器就死了或中间层死了，（50用户中，每人会有大量的数据操作，服务端的线程会成倍增加，用户一般不会买最好的服务器）
解决办法只有减少数据流量，优化查询语句，但会使一些操作不太友好。3 三层中数据穿过交换和路由设备困难重重，虽然现在有好多的方法，但在程序发布时，多多少少都会有类似的情况。流行的有现成控件，有sock控制等等多种办法和思路，但哪一种是最佳的。用户希望的最便宜的上网方式，无固定ip,最好是拨号上网。4 服务端压力测试，中间层峰值检查都是三层结构中需要重点考虑的。5...
6...大家还有什么想法，都说一说。
准备将c/s转换为b/s，对三层结构的实施心有疑问。1 c/s型大量数据传递通过局域网，速度和稳定性有保证，三层结构中的传递是通 过互联网，大量的数据据流动不是很现实。
原有的较方便的操作方法在三层中会有一定的问题。
如 infopower中的数据下拉列表lookupcombbox,中c/s可直接将部分数据字典表连到控件中，三层结构就不能采用类似这样的方法，数据量太大，往往一个窗口中，下拉列表有很多个。现在三层中都是远程得到一个表的数据，再写入下拉列表，客户端的响应时间就比较长（一个大字典表，有几万条记录）2 b/s三层中峰值流量会造成服务端程序不稳定，许多大型结构中，连接超50后，服务器就死了或中间层死了，（50用户中，每人会有大量的数据操作，服务端的线程会成倍增加，用户一般不会买最好的服务器）
解决办法只有减少数据流量，优化查询语句，但会使一些操作不太友好。3 三层中数据穿过交换和路由设备困难重重，虽然现在有好多的方法，但在程序发布时，多多少少都会有类似的情况。流行的有现成控件，有sock控制等等多种办法和思路，但哪一种是最佳的。用户希望的最便宜的上网方式，无固定ip,最好是拨号上网。4 服务端压力测试，中间层峰值检查都是三层结构中需要重点考虑的。5...
6...大家还有什么想法，都说一说。
在b/s模式下，三层都自己做很痛苦的。一般是，采用中间件做应用服务，采用大型数据库做
第三层的数据服务，自己做第一层客户端。
在b/s模式下，实现大下拉列表很困难，因为它的数据交互量太大。这类问题就是b/s的缺点。
既然是用B/S那么就不要再想有C/S那样的性能
的问题
就 server端游标 和 client 的游标
以及 封装 而已，
sql server +ado 也可以做三层
(
存储过程+自定义函数 = app server
client 的游标 = 客户端
)
理论上来说一般的ERP，MIS等做成B/S都没什么问题，象MSDN，比你的数据量多还是少？不也是用的ASP嘛
你主要的问题是数据量和并发数的问题
前者你可以通过优化数据库来解决，比如水平分割，列变行什么的，我还没见过哪个LOOKUPLIST有上万个条目，选都选到吐血，这系统怎么用啊？
后者你可以优化代码和服务器来解决，用户不买机器？这活就没法弄了，资源、进度、功能平衡是公理！