正方vs反方: 三层结构干吗用的? (300分)

正方(书上说):
三层结构主要是为减少实现企业逻辑的中出现的困难。所以在客户端仅仅保持对用户
的界面，和一些基本的数据完整性的验证等，而真正的数据、逻辑思想都保持在服务
器端，从而使得企业逻辑体现得更完善，企业逻辑的更新对客户端的影响也会减少到
最低程度！使客户端真正形成“瘦客户”。
反方(我说):
正方的观点很天真. 我们来分析一下吧:
1.
>>而真正的数据、逻辑思想都保持在服务器端，
>>从而使得企业逻辑体现得更完善
这么做, 那么服务端就是一个绝对不存在通用性, 和您的应用紧密结合的专用程序
既然是一个专用程序, 那么放在服务端和放在客户端没区别, 硬要说只有放在服务端
才"使得企业逻辑体现得更完善"纯粹大话, 难道所有两层程序都不能"使得企业逻辑体
现得更完善"吗?
2.
>>企业逻辑的更新对客户端的影响也会减少到最低程度!
更是想当然的说法了, 别告诉我企业逻辑的变更不涉及数据库的变更, 而数据库的变更后,
为了这个变更能体现到用户, 不改变用户界面简直是天方夜谭(别拿报表字段计算公式
的变更做反驳我的例子, 我一直认为这种把具体计算公式写入报表程序的方法本身就
是一种错误, 这本应该属于通用报表的范畴).
既然如此, 那么我们就非常不幸地得到了一个恰恰相反的结论:
一旦企业逻辑变更, 我们不但要更新服务端程序(没办法, 所有企业逻辑的实现不是都
在服务端吗?),
而且要更新客户端程序(也没办法, 企业逻辑都变了, 你告诉我说所有输入, 输出的数
据格式都不变, 那不摆明了是骗人吗? 而且您将数据完整性校验放在客户端的, 不改变
客户端程序怎么可能实现企业逻辑的更新?)
3.
>>使客户端真正形成“瘦客户”。
"瘦客户"这个提法我一直认为是骗人的广告语. 如果按它的定义, 那么"瘦客户端"所
"瘦"掉的, 应该是维护成本, 稍微用脑子想想就知道在具体应用中这个提法多么荒谬
了, 如果应用中没必要修改程序时, 那么不管哪种结构的客户端, 它都不需要维护,
如果由于应用变化而需要修改程序, 那么不管哪种结构的客户端, 它都需要更新维护.
而我们完全可以在客户端程序中加入自动下载更新的代码达到客户端免维护的目的.
反方观点如下:
我们并不是说中间层不好. 只是我们的目光不应该放在什么"中间层实现企业逻辑, 客
户端实现用户界面"之类具有欺骗性的观点上.我认为中间层的优势在于负载平衡和数
据调度, 附带数据完整性检验与访问安全性控制. 开发中间层程序首先要考虑的是用
它能降低网络数据传输量, 并考虑原始数据计算过程+传输最后计算结果与直接传输
原始数据或经简单过滤的原始数据交由客户端进行计算, 他们的效率到底哪个更高
(毕竟中间层针对的不是一个客户端, 它得同时服务于几十上百个客户请求, 复杂的计
算对中间层效率的影响将是致命的), 还要考虑以后更新时中间层与客户端程序更新的
复杂程度(既然客户端程序总是要改的, 何不尽量少改中间层程序?). 另一个值得考虑
的问题是访问安全性控制. 我们当然可以直接使用DBMS的安全机制, 但大多数数据库
产品都是通用的, 而不是针对某个特定用户的, 研究它安全漏洞的人也车载斗量. 具体
应用时它的安全性也就大打折扣了, 而用中间层来实现安全机制的话, 由于我们可以
针对特定用户使用我们自己的安全控制, 不具备通用性, 被破解的可能性微乎其微(谁
愿意花那工夫?), 而被隔离了的数据库本身则根本不必担心遭受外界的攻击了.
关于B/S结构, B/S结构的Client是browser, 我一直认为这种结构根本不适合实
现企业级应用程序, 只有专用Client(包括使用专用插件的browser)才能和企业的实际
应用结合起来, Browser做出来的东西(不下载针对专门应用的专用模块的话)除了花架
子外毫无实用价值. 如果使用专用插件的话, 这个插件我们可以认为就是我们的Client
程序, 它也符合上述我方观点.
总之, 反方认为, 三层主要用途是负载平衡与数据调度, 而企业逻辑的实现则不是中间
层的使命, 相反, 大部分企业逻辑应当放在客户端(为以后更新方便). 只有那些能大
幅降低数据传输量, 计算又不太复杂的部分才应当放在中间层. 另外, 客户端提供自动
下载更新本身的功能是必不可少的, 应当作为客户端程序的密不可分的一部分.

我都是同意正方的论点，三层的话，可以很容易编写在不同平台上通用的软件，如现在
邮政网就是用3层的

我很欣赏反方的观点和阐述。
我认为对于一个企业级的应用，如果是运行
在局域网内，最好用2层结构。简洁，高效。
有了版本验证和客户端自动下载（这在局域
网中很快），就能消解3层所提的优势。
在internet上的应用当然用3层结构好，这也
是B/S的意义所在。例如小黄提到的邮政网。

同意正方

正方，结合我的一个例子，谈一下我的体会。
我给一汽做过一个汽车运输方面的电子商务系统。首先我说一下这个系统的企业
逻辑，整个一汽的企业网按照不同的部门分成若干个子网，比如说，电子计算处
、规划处、汽车研究所等等，各个子网分配了不同范围的ip范围，各个子网之间
无法直接访问，必须通过代理。这样的做法是大中型的企业组建企业网时常常使
用的模式。另外，一汽有自己的内部www 站点，内部域名www.faw/，同时，还有
外部网站www.faw.com.cn。内部站点可以被所有的企业网用户访问，外部站点接
受internet访问。我所做的这个系统包括三部分：
（1）位于内部站点和外部站点的web order page 。asp网页，接受用户填写的
注册，订单，提供查询服务等等。订单的内容包括托运的物品的名称，重量，托
运人，起运地，止运地等基本信息，值得一提的是有一个所选车队字段，这个字
段是我一开始没想到的，起因是一汽的车队总共有10多个分车队，而每个车队都
有自己的“专长”，比如说一队都是轿车，二队都是火车等等。而一汽集团内部
通常一个部门总是使用同一车队的车。
（2）订单分配中心。基于上面的订单的选择车队，一般订单可以自动送达分车队
，但是也有例外情况，比如说internet用户，就无法了解这一点，因此internet
用户可以不选择车队，对于这样订单，就在订单分配中心根据订单的需求，分配
到具体的车队。
（3）分车队派车处。分车队处理订单的客户端程序。
对于这个系统，最后我们选择的系统结构是：
-----------------
| Database Server |
-----------------
|
-----------------
| App Server |
-----------------
|
-------------------------------------
| | |
----------- ------------- -----------------
| web page | | Order center| |若干分车队客户端 |
----------- ------------- -----------------
下面说一下，我们这样选择的理由：
像运输处的这样一个系统，如果不使用App Server，就会至少建立10-20个连接。
如果汽车厂的所有用户都这样来，那总共恐怕要有几百个连接，虽然win2000+
sql server 7的组合号称几百个也没问题，但是还是不要让它太累的好。
另外，这个贴子中提到的也都是我们所考虑的内容。我们的这个App Server也正
是整个系统的逻辑体现最突出的一部分，首先，所有的数据都集中在这里，而对
不同的客户端来说，能够看见的部分却是不同的。每个分车队能够看到的就是属
于它的订单。而事实上，在App Server上面做到这一点，轻而易举。而且，要改
变这个逻辑，例如，后来我们添加了一个订单的转让，就是自己不能处理的时候
把订单转让到别的车队，我们也就是在App Server上面添加了一个特殊的Query。
而客户端，我们真的没有改动，当然这里面有一个小小的技巧。实际上，我们想
的，分车队只要长眼睛就可以了，我们给它一个窗口。
使用这样的体系机构，我们突出的感受是，首先，我们基本没有在服务器上面
写多少的StoredProc，另外，我们在客户端也没写多少的Query 语句。而是在
App Server上面直接用程序流程来描述我们的商业逻辑。包括身份验证，数据
检查等等。而且在我们做的过程中，出现了多次我们对用户的需求理解不深刻
的情况，我想这个大家都碰到过，这个时候我们所需改动的也仅仅是App Server
而同时，我们客户端的程序，一直作为测试使用，这也许就是所谓的螺旋模型
吧，我软件工程不是很好。。客户端程序的大小也很小，而且我们针对运输
处的人员素质不高的特点，设计了一个很方便使用的界面，大量应用了拖放的
操作，在整个操作过程，如果操作正确，可以不用敲一个汉字。

lczhuohuo:能否介绍一下你的结构中的
app server和客户端都是用什么工具开
发的，还有数据库访问方式。

我支持正方:
对于反方提出的三点质疑我就引用Another_eYes自己说过的一句话:
"这是三层吗? 你自己三层没规划好".
我认为只要在系统分析和设计阶段,真正投入精力,严格按照面向对象的分析设计方法.在
设计阶段就贯彻分布式组件开发的思想.这样在编程实现阶段就减少此类疑惑.
举例来说:
<<别告诉我企业逻辑的变更不涉及数据库的变更, 而数据库的变更后,
<<为了这个变更能体现到用户, 不改变用户界面简直是天方夜谭
我正在开发的一套系统中,设计时就考虑到不同用户对业务要求的"大同小异",以及用户
喜新厌旧的特点.Client端的输入和显示界面不是死的,而是可根据用户要求自定义的,我
简单说明一下实现原理:
客户端装有本地数据库(dbase),数据库中除了存放着各类字典表以外,还有业务数据项描述
信息,该信息是以"事务"(系统中最小的处理单元,如某一个个人信息的录入),具体描述内容
有:
1、整体显示风格
2、需要显示的项目：项目标志、显示文字，显示方式，类型（百分比、日期、姓名、性别...），
关联字典，有效性规则.....
3、项目间关联校验规则
4、................
这样，如果数据库中多了一个字段，可以用专门定义规则的子程序修改中心数据库，并且
生成新的描述文件（文件型数据库）。修改中间层程序（将原有接口中的同名函数继承扩展
或重写，idl文件不变）。
客户端每次登录服务器时自动检查更新标志，如需要更新则下载相应的文件，更新本地数据库
重新进入客户端系统后，数据录入界面中将多出一个新增加的字段。
以上为例。
我们实际开发中，有大量信息录入的界面都是这样生成的。不但结构清晰、还节省了不少工作量
使程序维护变得简单。
请大家多提意见！

三层结构的思想应该是好的，但是设计一个好的中间层 App Server 却并不容易。

在客户用户不多的情况下，如用户数量不大于200的情况下，
两层已足够了，
三层我认为是为了提高现在的网页功能，如一个好的应用软件可能会发布在网上，让
网上的用户可看，如电子商务。 这时候两层就太。。。。
而用三层时，网页和本厂的客户端都好编，即瘦也。因为数据都从中间层来。

都是用delphi开发的，访问使用的是tcp/ip连接。

同意正方，观点就不说了！好用方便使用。我现在就准备做一个三层的！

irc记录：
[20:34] <左轻侯> 你看了dfw那个三层的贴子吗？
[20:34] <左轻侯> 我正在看
[20:35] <温柔一倒> 呃，看了两眼
[20:35] <左轻侯> 那个问题提得很好啊
[20:35] <温柔一倒> 哦，大概是吧。
[20:36] <温柔一倒> 我对三层不感兴趣，所以当时想说：
[20:36] <温柔一倒> 正方、反方、都是胡扯...
[20:36] <左轻侯> 啊？
[20:36] <左轻侯> 哈哈
[20:36] <左轻侯> 然则你以为？
[20:36] <Crab> ...
[20:36] <温柔一倒> 说难听的，我认为三层就是胡扯
[20:37] <左轻侯> ?
[20:37] <左轻侯> 何以见得？
[20:37] <温柔一倒> 技术不成熟
[20:37] <左轻侯> 啊呀，与这个无关
[20:37] <温柔一倒> 举个最直接的例子：那个贴也提到了
[20:37] <左轻侯> 技术不成熟，将来会成熟的
[20:37] <左轻侯> 我们现在是讨论三层的思想本身。
[20:37] <温柔一倒> 你说B/S是几层？
[20:38] <左轻侯> 三层
[20:38] <温柔一倒> 可是有什么三层的特征在里面呢？我是说逻辑上的
[20:38] <温柔一倒> 根本没有AppServer这个概念在里面
[20:38] <左轻侯> 因为我不能直接用IE去访问dbms啊
[20:39] <左轻侯> 怎么没有appserver？
[20:39] <左轻侯> CGI就是嘛
[20:39] <温柔一倒> 〉〉我是说逻辑上的
[20:39] <左轻侯> 有啊
[20:39] <左轻侯> 以dfw为例，
[20:39] <温柔一倒> 恩
[20:39] <左轻侯> yysun写的ASP，运行在IIS上，就等于appserver
[20:40] <温柔一倒> 所以我说：我是说逻辑上的
[20:40] <左轻侯> 没有appserver，我们就只能下个客户端去连MSSQL了
[20:40] <左轻侯> 是逻辑上的啊
[20:40] <左轻侯> 哪里不对吗？
[20:40] <温柔一倒> 你写asp，根本不考虑什么业务逻辑，完全和一个客户端程序c/s一样
[20:40] <Crab> b/s 的三层跟 delphi 的 midas 的三层，完全是两回事
[20:41] <左轻侯> 我所理解的三层，
[20:41] <温柔一倒> 只是给你提供了一种物理上三层的实现方式
[20:41] <温柔一倒> crab说得对
[20:41] <左轻侯> 就是dbms-appserver-用户界面
[20:41] <温柔一倒> 所以说三层这个概念还要先明确
[20:41] <左轻侯> 至于实现方式是什么，与我何干？
[20:42] <温柔一倒> 不对呀！
[20:42] <Crab> delphi 倡导的三层，是指它的 Midas
[20:42] <温柔一倒> 三层当中客户同样要写程序
[20:42] <Crab> b/s 只是另一种模式的 c/s 罢了
[20:42] <左轻侯> 不对，我不这么理解
[20:42] <温柔一倒> 对，crab和我观点一致
[20:43] <左轻侯> 呵呵
[20:43] <温柔一倒> b/s只是另一种c/s
[20:43] <左轻侯> 哎呀，你要这么说当然也没错啦
[20:43] <温柔一倒> 所以a_eyes
[20:43] <温柔一倒> 所以a_eyes说的就有问题了
[20:43] <左轻侯> 三层也只是两层的扩展啊
[20:43] <Crab> 三层的核心，应该是，它加入了一个 appServer 的东西
[20:44] <温柔一倒> 他说的反方观点并不是三层
[20:44] <Crab> 一切对后台的操作，都通过 appServer 进行
[20:44] <左轻侯> 对
[20:44] <温柔一倒> 所以你没看见贴子里面有人“引用”他原来说的话去反驳他么？
[20:45] <Crab> 这也是 delphi 中 b/s 可以和三层共用一个后台的精华所在
[20:45] <温柔一倒> 他说的三层有两个，一个物理上，一个逻辑上
[20:45] <Crab> 物理上？
[20:45] <温柔一倒> 可是它把这两个一个作正方，一个做反方
[20:46] <温柔一倒> 互相辩论，可不是出不了结果么？
[20:46] <左轻侯> 呵呵，反方的观点的确不明确
[20:46] <左轻侯> 我们并不是说中间层不好. 只是我们的目光不应该放在什么"中间层实现企业逻辑, 客
[20:46] <左轻侯> 户端实现用户界面"之类具有欺骗性的观点上.我认为中间层的优势在于负载平衡和数
[20:46] <左轻侯> 据调度, 附带数据完整性检验与访问安全性控制.
[20:47] <左轻侯> 他只是在争论中间层的作用
[20:47] <温柔一倒> 对呀，剑走偏锋
[20:47] <左轻侯> 那么，这个问题可以调整为三层的实现方式之争
[20:47] <温柔一倒> 他强调物理上三层的作用，可是也不应该否认逻辑上的作用啊。
[20:48] <左轻侯> 中间层到底是应该实现业务逻辑，还是只实现负载平衡之类
[20:48] <温柔一倒> 所以我说技术不成熟有所指的
[20:49] <左轻侯> 如果从这个角度来讨论，我还是站在正方一边。

对于我来说，更倾向于两者的结合，即：appServer + 不太瘦的客户端。
因为，如果把所有的完整性校验、商业逻辑都通过 appServer 来做，网络的流量
就会明显增加，网上就多了许多不必要的数据传输。为什么不让客户端承担一些
基本的校验，从而减轻服务器端的负担呢？
举个简单例子来说：
一个简单的校验，如：订单里，数量不能小于 0，
这种检查有什么理由要做在中间层？这是很基本的校验，应该由客户端承担。

继续
[20:54] <Crab> 对于我来说
[20:55] <Crab> 更倾向于两者的结合
[20:55] <Crab> 即：appServer + 不太瘦的客户端
[20:56] <Crab> 因为，如果把所有的完整性校验、商业逻辑都通过 appServer 来做
[20:56] <左轻侯> 呵呵
[20:56] <Crab> 网络的流量就会明显增加
[20:56] <左轻侯> crab，那是过渡时期的方案
[20:56] <Crab> 网上就多了许多不必要的数据传输
[20:56] <两面温柔一边三刀> 嗯，这个问题还要继续探讨
[20:57] <两面温柔一边三刀> 我只是说了我对三层的看法
[20:57] <Crab> 为什么不让客户端承担一些基本的校验呢？
[20:57] <Crab> 这点就如 asp/jsp + jScript 一样
[20:57] <两面温柔一边三刀> 我一直坚持不使用三层，就是因为理论上，技术上都不成熟
[20:57] <左轻侯> 以后的客户端会是通用的而不用专用的
[20:57] <Crab> asp/jsp 完成的是逻辑上检验，但客户端的 jscript 也是不可少的
[20:57] <两面温柔一边三刀> 但是无不排斥b/s，在我看来他和c/s没区别
[20:57] <左轻侯> 就象brower
[20:58] <两面温柔一边三刀> 嗯，又说到老问题了，客户端是否作完全通用
[20:58] <两面温柔一边三刀> 完全通用只能browser了
[20:58] <两面温柔一边三刀> 可是那样还是两层
[20:59] <左轻侯> 呵呵，我不认为
[20:59] <两面温柔一边三刀> 因为所有逻辑都在中间层，逻辑上没分开，就不是三层
[20:59] <左轻侯> brower不但是三层，而且只有通用才是真正的三层
[20:59] <两面温柔一边三刀> 不同意
[20:59] <两面温柔一边三刀> 因为所有逻辑都在中间层，逻辑上没分开，就不是三层
[20:59] <左轻侯> 那看各人的理解了
[21:00] <两面温柔一边三刀> 啊？
[21:00] <左轻侯> 我认为中间层就是应该负担所有的逻辑的
[21:00] <两面温柔一边三刀> 可这是问题的关键呀！
[21:00] <左轻侯> 客户端只是负责输入输出而已
[21:00] <Crab> 不应该负担所有的逻辑
[21:00] <两面温柔一边三刀> 那和两层有什么区别？
[21:00] <左轻侯> 多一个客户端啊。
[21:00] <两面温柔一边三刀> 我faint!!
[21:00] <左轻侯> 你可能认为这个客户端无关紧要，
[21:00] <Crab> 一、基本校验，如：订单里，数量不能小于 0，
[21:00] *** Joins: JoyHero (SmileInThe@202.106.147.12787)
[21:00] *** 么共频道 sets mode: +o JoyHero
[21:01] <Crab> 这点为什么要做在中间层？
[21:01] <左轻侯> 不过整个internet都是建立在这种三层之上的。
[21:01] <两面温柔一边三刀> 关键是还是回到我刚才的观点了
[21:01] <Crab> 这是很基本的校验嘛
[21:01] <两面温柔一边三刀> 你说的是物理上的三层
[21:01] <两面温柔一边三刀> 而不是逻辑上的三层，这两家争论，怎么得出结果？
[21:01] <左轻侯> 关键在于三层的定义
[21:01] <左轻侯> 我认为的逻辑上的三层，
[21:02] <左轻侯> 就是中间层负责所有的逻辑，
[21:02] <两面温柔一边三刀> 啊？
[21:02] <左轻侯> 客户端只负责输入输出。
[21:02] <两面温柔一边三刀> 我faint！！
[21:02] <Crab> 二、现在的客户端速度非常快，处理简单的校验绰绰有余，根本没必要让服务器来承担这些工作
[21:02] <两面温柔一边三刀> 那不就是站在反方的观点了？
[21:02] <左轻侯> 不是啊
[21:02] <两面温柔一边三刀> to 左
[21:02] <两面温柔一边三刀> 怎么不是？
[21:02] <左轻侯> 反方认为中间层不应该负责逻辑，
[21:02] <左轻侯> 我认为应该
[21:03] <左轻侯> 就这样。
[21:03] <两面温柔一边三刀> 呵呵，极左和极右从来都是殊途同归
[21:03] <左轻侯> 哈哈
[21:03] <左轻侯> 何必贴标签呢，重要的是问题的实质
[21:03] <两面温柔一边三刀> 所以你还是反方，只是走到另一个极端
[21:04] <两面温柔一边三刀> 这不是很说明问题么？
[21:04] <左轻侯> 说了半天，还是我们对三层的理解不同
[21:04] <Crab> 嘿嘿
[21:04] <两面温柔一边三刀> 对呀！
[21:04] <两面温柔一边三刀> 我一开始不久在强调么？
[21:05] <左轻侯> 反方认为中间层不应该负担逻辑，
[21:05] <Crab> 我想
[21:05] <左轻侯> 我认为中间层应该负责所有逻辑
[21:05] <左轻侯> 而一刀认为三层不成熟，最好用两层？
[21:05] <两面温柔一边三刀> a_eyes用不同的理解作正反方，得不出结论
[21:05] <Crab> 双方所说的三层，应该是指 D 里面做的三层服务器，要求把商业逻辑做在其中的
[21:06] <两面温柔一边三刀> 你也是一样，你的观点成了第三方，但是和反方不形成争论
[21:06] <左轻侯> 这话也没错。
[21:06] <两面温柔一边三刀> 因为根本没有可争论的
[21:06] <左轻侯> 但是里面又说到了B/s啊
[21:06] <两面温柔一边三刀> 但是和正方的理解仍然不通
[21:06] <左轻侯> 这跟D里的三层可没有关系。
[21:06] <两面温柔一边三刀> 对，所以我说不能混在一起
[21:06] <Crab> ？
[21:07] <Crab> 本来双方讨论的就是 D 的三层啊
[21:07] <两面温柔一边三刀> b/s只是物理上的三层，或者你说的三层
[21:07] <左轻侯> 关于B/S结构, B/S结构的Client是browser, 我一直认为这种结构根本不适合实
[21:07] <左轻侯> 现企业级应用程序
[21:07] <左轻侯> 这和D的三层有什么关系？
[21:08] <两面温柔一边三刀> OK，我要去洗澡，在此之前总结性陈词
[21:08] <左轻侯> 哈俣
[21:08] <左轻侯> 哈哈
[21:08] <两面温柔一边三刀> 一种三层的理解是逻辑分开，客户/中间层各负责一部分
[21:09] <Crab> 这是我说的三层
[21:09] <两面温柔一边三刀> 从而客户“较瘦”，中间层负责核心
[21:09] <两面温柔一边三刀> 另一种是逻辑不分开，但又分为两派
[21:10] <两面温柔一边三刀> 逻辑都在中间层/中间层不负责逻辑
[21:10] <左轻侯> 还有一派
[21:10] <两面温柔一边三刀> 什么？
[21:10] <左轻侯> 就是一刀说的双方都是胡说
[21:10] <两面温柔一边三刀> wo faint!!
[21:11] <两面温柔一边三刀> 不要打断我
[21:11] <两面温柔一边三刀> 但是双方都可以说对方不是三层，而正方则说他们都不是三层
[21:11] <两面温柔一边三刀> 于是温柔一刀说：可见三层是胡扯
[21:12] <左轻侯> haha
[21:12] <Crab>

另外，我还想指出的是，这个App Server在商业逻辑中的更一般的使用，
它的作用其实相当于我们购物时候的商店的作用。在现实生活中，我们可以直接
从商品的生产者那里直接购买我们所需要的产品，但是我们很少这样做，我们总
是去商店，为什么这样呢？似乎这不是一个问题，因为商家那里不仅有一个厂家
的产品，我们可以从众多的产品中进行选择；上加的存在还有一个好处就是，如
果在一家商店中，我们想要的商品已经出售完毕，我们完全可以到另外的商店去
购买，甚至某一家商店倒闭了，我们仍能买到所需要的商品；而且，事实上，商
店对于生产厂家来说也是必不可少的，有了商家，生产厂家可以集中精力于生产
，提高产品质量，降低成本等擅长的东西。当出售产品时，厂家会直接把商品出
售给商店，而不是最终用户。现在我们把数据库中的数据想象成一种商品（
事实上，这也是电子商务的精髓），App Server是商店，Database Server是生产
厂家，客户端是消费者。如果我们按照这种思想去构件整个系统，我们不难发现
需要集中精力做的，就是App Server。因为当我们购物的时候，购物的成功与否
，质量如何，与商店的关系很大。而名牌产品就是名牌，自己有多上前也基本上
是固定的了。
不知这个比方是不是恰当。：）
店

lczhuohuo兄言之有理
高手啊
我认为我说的那种模型（中间层负责所有业务逻辑，而客户端是通用的，例如b/s）将会
是发展方向。
b/s之所以未能广泛用于大型的企业应用，是因为目前由于种种条件，企业应用还局限于
地域集中的局域网中，因此c/s仍然是主流，反方的胖客户端也有道理。但在将来，当基
于宽带internet的远程统一协作成为主流的时候，想想c/s的工作量吧！lczhuohuo说的就
是一个例子。
反方尽可按照他说的去做，但是大家都按照他说的去做的话，整个internet都要玩完。
想想看吧，你现在可以用一个IE浏览dfw，如果把业务逻辑都做到客户端的话，你就得为
每个网站下一个客户端！而且网站一升级，你的客户端也要升级！
未来的企业网，就是现在的internet。
而且，宽带技术的成熟，xml的发展，等等，都已经为这次革命做好准备了。

看这一个贴子我晕了两次 :-(
1.洗澡你一也贴上来了？
（再说贴的太长，重点散乱，能读完的肯定不多，我建议你整理吧，你还不同意...）
2.第一次发现了贴子最后出现广告...

这样比较富有生活气息

居然你的贴子在我之前，真没想到。
b/s 结构虽然方便，但并不是万能的，比如，客户端要做一个很复杂的报表，你用web
就办不到，虽然可以在服务器上做好，传过来，但这样的安全性很值得商榷。

给位都是好手！！