通过MIDAS,你可以把CLIENT/SERVER应用分发到层,每一层实现一种逻辑上独立的功能。多层应用的优点就是你可以很方便的替换应用中的每一层,因为每一层都不知道其他层是如何实现它们的功能的。并且,每一层通过特殊的方式和其他层通讯,并只对其他层提供的服务感兴趣,而不是如何提供这种服务。最简单的分布式应用是三层式应用。在三层式应用中,客户端的角色就是显示数据。中间层处理所有的交易逻辑,第三层是数据库服务器。

解决方案 »

  1.   

        多层应用的优势在你比较传统应用和多层应用的维护时会变得很明显。当你不得不修改CLIENT/SERVER应用时,你需要重建一个新的版本并重新部署它。如果有很多客户,你可能需要整周的时间来做这件事。    例如,假设你在创建一个用于计算销售人员工资的工资表的应用。工资依赖于销售人员的销售情况,突然,老板告诉你计算方法需要修改。    在CLIENT/SERVER应用中,你需要修改客户端的程序。然而,如果你已经把交易逻辑(计算方法)从用户接口中分离出来,你就只需要替换中间层的应用。比较修改100个客户端和只修改中间层的花费,不言而喻。    然而,节省开支并不是建立多层应用的唯一理由。当第一层只是用来显示数据,建立INTERNET应用就会变得更经济。例如,我的很多客户问我如何创建他们最好的基于WEB的应用。我通常告诉他们解决这个问题的最好方法就是首先用MIDAS建立一个多层应用的版本,然后为它创建一个WEB用户接口。当然,分布式应用对多层式来说解决起来并非难事,但是一旦你体会到了这项技术的优越性,你就会很快知道它什么时候有用或无用。 
      

  2.   

    全文见http://jennykiller.163.net/dp20001103.htm
      

  3.   

    1.安全性:主要是屏蔽了c/s中频繁的客户与数据库的交互(c/s数据库相对客户c是完全裸露的),有效的保护数据库的安全。
      

  4.   

    crob,首先谢谢你的文章!能不能站在用户的角度谈谈呢?用浅显易懂的语言,谢谢!
    airhorse,继续呀!
      

  5.   

    airhorse(编程至尊宝),多写点嘛,老兄!
      

  6.   

    c/s---- 客户/服务器结构,早期的c/s结构都是二层的,这样做带来维护上的困难,当客户端的应用程序要升级,哪怕是一点点的改动,都需要对每个客户端进行更新。因此加上一个中间级应用程序服务器,在其中整和组件,数据处理、分析和交换公用模块,以及前后端联结模块,这是所谓的逻辑结构上的三层c/s结构。在这个结构上,客户端已经有些瘦化了,只处理用户界面,比如用户的数据输入。实际上是将原来在客户端应用程序中的公用组件和模块移至中间层,因为我们经常要更新的是这些东西,所以要升级时,只需要升级中间级的应用程序服务器就行了。中间级应用程序服务器负责客户端和后端服务器(比如数据库server)的通信和数据处理。
        
    b/s-----browser/server,浏览器/服务器结构,可以将它看成是c/s的一种特殊结构。(先这些) 
    一个常见的b/s实例是browser(ie)+iis+asp(active server page)页面+ms sql server.事实上,这时候的客户端应用程序是ie,你的好处是不必在编写客户端的一句代码,不是吗?(除非你想自己做一个浏览器),microsoft已经给你做好了一切。看上去,你像在做一个零客户/服务器系统。所有的asp页面被放在web服务器上,由iis解释执行,向后端sql server取数据,然后再返回这些数据给前端的浏览器。如果“偏激”一点讲,将这些asp程序当作“客户”,然后asp程序调用ado或者用户自己编写的组件来对后端数据库进行操作,也可以。但基本上,我们要做的是升级iis版本,或者ado,或者你的组件,或者修改asp页面来提供internet/intranet服务.这是b/s的好处,易维护,操作简单(对最终用户而言),但是b/s结构存在安全性、实时性差,很难实现复杂的分布式计算。对于提供信息服务,b/s结构是非常好的。
      

  7.   

    airhorse(编程至尊宝) :说的精彩
      

  8.   

    我认为至少有以下两点优势
    1、有利于升级和维护
       当client非常多时,3-tier/n-tier的这个优势将明显的表规出来。如果有新的需求,开发人员可以只更新中间件部分。
    2、可以限定用户的情况下,增加用户访问数。
       可以利用pooling技术(资源共享)实现这一点。
      

  9.   

    这正是我毕社的题目一部分:把我的翻译给你吧!
    1.2.1 两层体系结构模型
        两层结构按功能可以分为客户层和服务层,如下图1.2.1所示:
                     
    图1.2.1
    客户层包括应用程序和一个或多个JDBC驱动程序,其中应用程序完成下列功能:
     表达逻辑
     商业逻辑
     多状态或分布式事务的管理
     数据源管理
    在这种结构中,应用程序直接和JDBC驱动程序交互,包括建立和管理物理连接以及处理特定数据源实现的细节。应用程序可以使用特殊的机能,使用非标准特性对性能进行协调。
    这种结构的有以下缺点:
     其下层结构和系统级功能的混合式表达及商业逻辑,对一个明确定义的体系结构编写可维护的代码有一定困难。
     由于编写的代码和特殊的数据库操作,致使其代码缺少灵活性,如果和多个数据库操作,应用程序必须清楚的知道各个数据库。
     由于应用程序一直和一个或多个数据库连接直到它终止运行,所以限制了并发执行。在这种结构中,JDBC驱动程序和相应的数据源管理着执行的结果,升级性以及有效性,如果一个应用程序和多个驱动连接,它必须知道什么时候某个数据和某个驱动连接。
    1.2.2 三层体系结构模型
     三层结构是增加一个中间层来封装商业逻辑和下层结构,如下页图1.2.2:
    这种结构可以提高企业级应用程序的执行性,可升级性以及有效性。从功能上看可以如下分各个层次:
    1.客户层——一个薄层,执行和用户的交互。Java程序和Web浏览器都是典型的客户层执行工具。客户层和中间层交互,但不需要包括任何低层数据源的功能。
    2.中间层服务——中间层通常包括:
     和客户层交互并且执行商业逻辑的应用程序。如果这个应用程序包括和数据源的交互,他将要执行更高级的抽象,如相对于低级的API,它会执行DataSource对象和逻辑连接。
     一个应用程序的服务器,它提供支持底层结构的某个大范围的应用程序,它还可以包括管理,物理连接池,事务处理管理以及屏蔽不同的JDBC驱动之间的差异,后边这一条可以使我们可以编写更加灵活的应用程序。该角色可以由J2EE服务器来实现,应用程序服务器执行更高级的被应用程序和JDBC驱动径直交互的抽象。
       
    图1.2.2
     JDBC驱动提供和底层数据源的连接,无论支持底层的数据源是何特征,每个JDBC驱动都执行基本的JDBC API。驱动层可以屏蔽基本的SQL99语法和本地数据源支持的语法之间的差异。
    3.底层数据源——数据存放的层。它包括相应的DBMSs, 传统的文件系统,面向对象的DBMSs, 数据库,电子数据表或者别的表达数据的方式。唯一的要求是相应的驱动要支持JDBC API.
      

  10.   

    根据自己多年的编程心得,随便侃侃。
    从站在客户的角度来说,主要是
    1.整个处理安全性大大增加,因为同后台数据库的操作基本上放在中间程,即应用服务器上。
    2.系统以后的升级极其容易,如客户想将其转变为intranet下或internet下B/S架构下系统,
    基本上只需修改前面显示的代码即可。
      

  11.   

    还有一点:
    中间件(如MTS, TUXEDO等)通常还担负了事务协调器的角色
    即Transaction Coordinator或Transaction Monitor
    可以处理全局事务,即需要多个资源管理器(数据库,消息队列等)
    参与的事务,事务协调器可以保证他们的一致性
      

  12.   

    这个与dcom,ejb有关系吗?
      

  13.   

    基于三层结构的开发我做了近两年,最近有一个感想,总有一天我们会返朴归真用回C/S的
    1.速度慢.
    2.开发成本高.
    3.应用服务器昂贵,并且,相对于大多数小型应用来说,根本没有这个投入的必要.(你试试,让那些windows都用盗版的用户买个AS看看)IT界的技术总是风起云涌,目接不暇的,我们往往不去进行具体的分析,就匆忙上马,完全不理会普通客户和普通程序员受得了受不了. 并且总要迫不及待的宣称:我们用的是最~~先进,最~~潮流的东西,言下之意就是:我们要多收费,乱收费哦~ 当然,我不是要否认多层结构的理论优势,我只是想说,我们要做适合国情的东西,踏踏实实的来.
      

  14.   

    下面是我的观点:
    为什么要采用组件化设计
            传统应用程序和组件化程序的比较
           优点:
    2. 更新容易,组件可在运行时替换
    因为组件应用程序是在运行时动态连接的,所以只要接口不变,新版本的组件可任意替换老版本的组件。
    3. 可定制的应用
       可根据用户的不同喜好动态定制。
    3.协作开发
               由于COM组件的语言无关性,可采用几种开发语言协作开发。
    4. 节约成本,可重用
           可建立自己的组件库,在开发时直接提取使用,大大加快开发进度。
    5. 使复杂问题简单化
           可将大型复杂的系统,分解成较小的模块,降低了系统设计和开发的复杂性。
    6. 合理利用资源
    1)、从分布式组件的部署上考虑,提高系统性能
    2)、从设计角度考虑,使具有不同特长的开发人员都能发挥自己的专长,人员可以灵活配置,不同的阶段使用不同人员。
    7. 容易管理
           一个好的设计它的进度应该是可控,可预见的。同时它应该有良好的附加文档。
    8. 易与维护
    这是COM组件的封装性带来的好处。
    9. 设计更完美
         能充分利用面向对象的设计方法,设计的组件更具人性化。
    缺点:
    1. 版本比较难于控制
    2. 对接口的设计要求很高
    3.  团队协做要求更高
      

  15.   

    多层设计和面向对象未必是个等号
    特别是com+,强调的是无状态的组件设计,是过程化的对象