大部分公司的系统都用c/s就足够了。
但是在规模扩大的情况下,也许对系统的结构要求就不是线性的了,如果一个系统有共同的
业务逻辑层,仅仅是每个客户端的界面上有所不同,把业务逻辑放到客户端或数据库上都不合适,
也许就要考虑如何抽象出单独的业务层了。
我孤陋寡闻,除了internet还不知道有哪些系统用的是典型3层或多层结构。
我是来学习的。报个到随便说两句。

解决方案 »

  1.   

    关于投资应用服务器还是数据库服务器能带来更好收益的问题,到底有什么实际的例子或者评测数据吗?在现在大量数据都能够作到并行处理,如DB2 EEE版本,在数据库服务器上的多投入带来的收益是很明显的。
    而且很关键的那个如何可能将业务逻辑封装在中间件的问题,我不论如何都认为不大可能以低成本和快速的方法实现。
      

  2.   

    成本的问题你可以发挥你的想象慢慢算。用midas结构代替c/s结构,对于开发来说很重要的一点就是把业务逻辑封装在中间应用服务器上,那么客户端就可减少许多重复的逻辑运算,实现廋客户的目的,并且,在客户端并不需要安装bde,odbc以及数据库client端程序就可运行;同样,原来许多由数据库承担的负荷可以转由多个应用服务器来承担(应用服务器的价格远比数据库服务器便宜得多,如果用户突然增加一倍,仅需花几千大洋购置一台普通机器就可搞定,而不需大张旗鼓地进行服务器升级),这种方法就解决了目前由c/s结构所带来的最大问题(在运算量巨大的时候。你说的深圳移动的客服中心其实其运算量并不会很大的,虽然其客户端很多)。
      

  3.   

    无法发挥想象,你有没有实际的例子。仅仅靠几千元的中间件服务器是无法完成用户数量增加一倍的冲击,这是我在我们公司工作总结出来的结论。还有就是你的计算量大是什么意思,在大多数
    企业的应用中,都不可能找到大量的计算,毕竟不是搞3D动画或者粒子计算,主要是在作连机
    事务处理。
    你说了半天将业务封装在中间层,而以我的实际经验这几乎是不可能的。看看我举的最简单一个银行的例子,你如何封装到中间层?我们公司的业务系统在发生业务逻辑变化时出现的实际情况是中间件和客户端都必须升级。bde odbc不过是一次安装的东西,三层应用,客户端仍然要不断升级。