图14.四层架构

    当表现组件之间需要大量的协调，并且需要在它们之间共享很多资源的时候就需要四层开发方式。例如，由于性能问题的缘故，缓冲是必要的。对话层允许很多不同的表现组件利用缓冲提供的性能优势。
    同样，如果某个客户端被迫作出多个、潜在的复杂的分布式结论，就可以考虑把这种逻辑封装到应用程序的一个对话层中。

    很多因素表明考虑四层开发方式的需求为数众多。很明显，任何四层系统预期的生命周期很长。已有的组件和子系统的重复使用对于引发与四层系统相关的费用来说通常都是足够充分的理由。同样，预计个别组件会频繁改变设计的目标的环境需要把系统的主要部分与组件实现中的变化隔离开来。四层方式提供了对随技术的发展（包括传统的和新的技术）组件和子系统不断地移植的支持。此外，四层系统比三层系统更容易升级。

    其它一些考虑因素包括组件的可靠性是未知的或可变的系统。在间歇性的组件失败中，四层系统可以轻易地合并运行时发现机制（runtime discovery mechanisms）以切换到不同的组件实现上。有四个或多个层次的很多复杂系统最少提供了发现新能力（例如，涉及到新的Web服务实现时，它们就实现了UDDI记录）的一些能力。如果环境利用了多个、潜在地冲突的技术，四层系统提供了用于管理对话管理层（session management layer）或业务域对象层中的差异的机制。同样，如果客户端有多种不同的应用模型，而这些模型都需要共享共同的数据资源，那么四层模型也可能是理想的。经常地，在其它的应用程序组件不希望阻塞并等待资源，不得不在对话层中管理客户端的访问的环境中，应用程序组件允许业务域组件处理资源管理的问题并能够经受得住等待大多数资源。

    对等（peer-to-peer，P2P）架构方式对于多数需要高度可升级的系统是理想的。同样，当分布式组件需要协调完成某种事务并且通讯以及其它组件的可靠性可能变化的时候，它们也是有用的。在开发P2P系统的时候操作环境很容易被理解是非常重要的，因为不好的习惯可能导致重大的灾难。同样，当使用P2P技术的时候，接口的标准化和不允许修改也是很重要的。被迫应付多个P2P网络的不兼容的版本简直是个梦魇。

    N层和/或这些方式的组合（图15）应该仅仅用于十分复杂的、由多个软件生命周期不同的子系统和组件构成的系统。这对于大多数大型的不同种类的企业系统是真实的，在这种情况下，在任何时候组件都在升级、更换或添加。对于这种系统，考虑的事项必须通知系统组件的管理部门。

图15.N层和对等架构的组合

    哪些特性值得使用复杂的N层系统呢？通常，它包括管理用于增强用户体验的大量数据的系统。其需求可能包括记载了用户的概要信息、允许用户设置参数控制Web页面和应用程序、管理复杂的安全需求（例如用于控制资源的访问控制列表）、允许用户要求后端应用程序中的存储管理和规则执行的进行改变等一些Web站点和应用程序。

    有了N层应用程序，应用程序的功能被分解为大量的逻辑层，它们可以分开维护和配置。每个层次的功能没有三层应用程序那么标准，并且经常把很多层合并成一组来提供表现、应用和/或业务逻辑和存储管理功能。支持多个层次的主要优点是更容易修改某个层次而不需要改变很多层次（在大多数情形中不需要改变其它任何层次）。此外，通过变更一个或多个层次的分布或载入，应用程序能够被扩大为处理大量的用户负载和/或数据。通常这种缩放对于其它层次是透明的，在很多情况下还是自动的。实际上，多层架构被设想为跨多个计算机和处理器分布程序，而不是在某个应用程序中定义软件的边界。