有经验的大侠讨论，Delphi的多层应用。

[vision2000]

本人用过PowerBuilder，Delphi，VB，JAVA等工具。
设计和编写过诺干B/S,C/S系统，分布式系统。
最终发现一些问题，我认为经典的设计模式是:C/S
J2EE的解决方案，复杂且难于除错。我对B/S模式甚至反感，原本浏览器本来是浏览网页的，我们做的信息系统做出来还得象网页，而且浏览器占用资源大，很多时候要用脚本控制网页，用起来及其不方便，特别是数据多的时候录入，专用于查询数据还可以，其他不舒服。
我认为B/S模式最大的好处是不用在客户端更新（暂且不谈兼容手持设备），但是很多基于B/S的系统仍然需要下载控件，而且容易受攻击，如果我们的系统定制一个客户端有智能更新的功能，并且自定义应用协议，不就跟浏览器一样方便了？比浏览器安全了？而且一些业务逻辑也可以分散一些简单的到客户端，降低服务器的压力，岂不更好？网络的传输专注于数据的传输。
象Delphi的多层解决方案能解决大部分问题，而且编程较简单，可维护性好。是解决企业应用的好方案。大家有何意见？
其实紧跟最新技术没什么必要，什么.NET,EJB,Struts等都没必要，那只不过是别人在测试哪种解决方案是最佳？或者在寻求最佳方案。

[大连刘]

用户就它骂的大白菜！

同意楼主观点。
我各人倾向于C/S结构。
B/S结构的东西，抛开用户的特疏需求的，实际最大的便宜是给了开发者，这些开发者还拼命借口向用户要钱，用户就象傻狍子一样的可劲儿得往里扔。

[chenminghong]

这些方面我不太懂，但是是个很好的话题，顶

[ssq237712]

支持。
但现在市场就是跟风，P大的系统，用户都一知半解的要用B/S方式，气死人啊。

[ssq237712]

如果从技术层面上讲，新技术有很多可取之处。
我比较倾向于网内C/S操作，B/S查询。经济实用

[vision2000]

我还谈论一下我参与一个大型企业系统的设计：
公司有N个分公司，分公司有N个分部
总公司计算机中心有大型数据分析系统，包括数据库和应用服务器
分公司与分部公用一个数据库服务器，在分公司设计一层应用服务器，各分部连接该属分公司的应用服务器。而且分公司的应用服务器跟总公司的应用服务器连接，用于往总公司传送相关信息。
分公司可以通过各自的应用服务器互相通信。
本来我建议用Delphi实现，结果被夹攻而死，而采用EJB和B/S，后来EJB太复杂，有点搞不下去了，我也溜算了。

[qixiao]

见仁见智，B/S结构的灵活性也是有目共睹的，但无论从强壮性还是安全性上都和C/S相差甚远。而C/S结构的程序如果在广域范围使用也是有诸多不便

用到合适的地方就好了

我也用.NET写过一些B/S程序，感觉的确没有Delphi来的方便，尤其是涉及到权限比较高的操作，很让人头疼，而要客户明白这些却需要费一番周折

[wozhuchuanwei]

帮
希望大家继续

[yanxiatingyu]

与楼主有同感，我也是专注于C/S系统的开发，发现在设计的功能和灵活性以及安全等都比B/C系统好，但，在面对广域范围内用户不确定的情况下，B/C显得更开放一些，所以我建议：在做一个公司内部（包括很多的分公司，）的管理系统，要实现很复杂的业务逻辑，不对网上那些闲云野鹤开放的时候，做成C/S系统；而面对不确定的对象（上网用户），向他们发布信息，对于那些不确定的对象来说只是简单的信息查询，这时做成B/C系统，或者是两者的结合，取长补断。

[leon2k]

我也设计过C/S、B/S系统，两层、三层、多层、分布式(分散式)

但是我最喜欢C/S结构的程序，可以有最大的灵活，实现复杂的功能，程序更新的问题，在我的系统中都有一个自动更新模块，一连接到服务器就可以检查出新的版本，根本需要担心发布的问题。将配置写成系统自动配置，那么不就什么事情都没有了吗？

我觉得，现在的.NET有一个优势，在于设计分布式系统，但是还是比Delphi的要麻烦的多。

对于WEB结构的程序，从一开始，我就觉得不适合做企业的应用系统，因为企业的应用系统交互复杂，逻辑复杂，WEB程序又非常难以调试。我一直认为是鸡肋。

我觉得现在提出的RIA（胖Internet客户端）是个很好的理念，但是现有的技术都非常不程序，主要是现有的程序框架不适合RIA。我觉得大概等到06左右，它会变得比较适用。