C/S、B/S及三层结构
C/S、B/S及三层结构
　　编者按: 为了更贴近软件开发人员，为他们提供一个技术交流的平台，从本期开始，实用技术栏目更名为应用沙龙，下设软件开发工具及技术、数据库、网络管理和知识窗四个子栏目。虽然栏目的设置和名称变化了，但不变的是我们的读者定位，是关注我国程序员的成长、为软件工程师服务的宗旨，是为我国的软件人员提供一个交流园地的目的，因此我希望您对我们的关注和支持也一如既往。今年，在新的栏目安排下，我们将特别加强与读者的交流和互动，就一些主流的软件开发工具的最新近展和软件开发的热点技术进行探讨，对数据库技术和网络管理进行研究，对程序员的职业规划进行交流，我希望在您软件技术水平的点滴提升中，在您人生经历的每一次成功中，都有我们相伴左右。
　　本期除了常规的知识窗外，我为您奉上四篇文章：《C/S、B/S及三层结构》（上）这篇文章是作者为所在公司的软件开发人员进行培训时的讲稿，虽然作者不是一位专家，对一些问题的看法也未必准确，其内容也不是当前最热门的话题，但是它是第一线软件工程师的切身体会，是作者本人的实践经验总结，言之切切，所以我选中了它；《漫漫J2EE学习路》是一位网友的帖子，有读者向我推荐了它，他告诉我，在Java论坛、计算机世界网和CSDN等不少知名网站的Java频道都有转载，因此我也就将这篇文章推荐给了各位Java爱好者，这篇文章给那些Java爱好者指出了一条学习的道路，相信Java爱好者不会失望；《Henry的VB.NET之旅》是本栏目所做的一次尝试，此次一改过去传统的技术讲座形式，用一个个故事来讲述VB.NET的知识点，我们希望读者在轻松幽默的学习过程中，掌握VB.NET; 《XML和数据库》揭示的是当前热点XML和数据库的关系，关注XML技术的人不妨一读。
　　对一名软件开发人员而言，计算机语言只是手段，开发平台是工具，而技术才是真正的实现。所以任何一位在软件开发领域奋斗的朋友，都应努力把握目前软件开发的主流技术与知识，才能在这个领域中立于不败之地。
　　多层模式（N Tier）
　　从事过Windows下MIS程序开发的人，都很清楚C/S是怎样实现的，在此笔者并不是要抛弃两层模式，只是希望通过笔者的描述帮助大家建立概念及了解三层结构带给我们的是什么空间。
　　误解一：C/S退出历史舞台了
　　笔者以为，C/S并没有到这么惨的地步，任何一个项目或任何一种方案，都要分析一下它实现的是什么东西，并且它将要面对的最终用户是什么性质。比如开发一个在Windows下运行的程序，或开发一个在局域网内并且只针对少量用户的程序，或者一个管理程序、后台运行程序，未必一定强求使用多层模式，因为它并不能给你带来什么，反而会增加你的工作量与维护量。
　　我们不应该单纯追求技术的先进性，而要追求实用技术，当你要实现一个方案时，你要分析项目的性质及最终用户，然后再寻找能解决你问题的最实用手段。因为用户并不关心你采用多么先进的技术，用户关心的是可靠（Reliable）、快速（Rapid）、方便（Convenient）。
　　误解二：多层模式只适用于大型项目
　　这是常见的一种误区，包括笔者自己，在进入N Tier领域之前都是这种想法。但随着对N Tier了解的不断深入，才发现这种理解是错误的。具体的选择应根据项目的特点及面向的最终用户群性质来决定。
　　如果你的项目运行在广域网，就必须考虑数据的安全以及带宽问题，或者当你面对的是普通用户，他们不可能完成复杂的程序设置、安装等工作，或者简单地讲，如果你要实现一种零成本或者最小成本的最终用户维护，你就必须考虑采用N Tier的B/S模式来开发该系统。
　　我们习惯把N Tier模式称作三层结构体系，因为N Tier实际上是三层结构的变体。正确理解三层结构对于程序员而言非常重要，因为这里面包含着许许多多的理论和技术背景，融合了多少天才式人物的奋斗，才有了我们今天成熟的N Tier开发基础。
　　三层结构的技术实现手段
　　要开发一个三层结构，这些技术是必不可少: 中间件、通信协议以及交易模式。
　　中间件 中间件是构造应用服务器不可缺少的。目前在Window平台下通用的三层结构中间件有下面几种: Midas、CORBA、COM/DCOM/COM+以及Asta。
　　Midas是Borland公司从Delphi 3开始达到应用级的产品，功能强大，也是Borland公司的旗艇产品，可应用在Windows及Linux下; CORBA是OMG（对象管理组织）推出的产品，有强大的跨平台能力; COM/COM+是Microsoft的拳头产品，也是每次Microsoft都要宣传的理念之一，目前已整合到操作系统中。它的结构非常庞大，如果把Midas比喻成一只野马，那COM+就像是一头狮子。狮子看起来比野马强壮很多，但要驯服它却很不容易。最后一个是Asta中间件，可能大家不太熟悉，实际上从1997年开始Asta公司就致力于发展这个产品。它内嵌了Socket连接，有强大的“消息”开发机制。
　　通信协议（或连接方式） 通用的中间件连接模式有TCP/IP（如Socket）、DCOM、CORBA等。程序员经常会把DCOM与COM混淆，实际是有区别的，COM只是一种服务提供，而DCOM才能使COM真正发挥它的魅力，DCOM在COM的基础上增加了分布的概念。目前，微软又新推出了.NET，对DCOM进行了发展和完善。
　　Midas既可使用DCOM连接，也可使用Socket连接，Borland公司在Delphi 5中对Midas进行了核心性的改造，所以要使用Midas，一定要看Delphi 5以上版本的书籍。
　　COM/COM+只能使用DCOM连接，CORBA使用自己的连接协议。这里笔者还想提一下DCOM，DCOM连接虽然优点很多，但设置过于复杂，所以连Microsoft也承认其缺陷。Microsoft在.NET平台中将首推SOAP连接协议，SOAP是建立在HTTP上层的协议，主要为了适应XML的发展，目前已得到许多大公司的支持（如IBM、Oracle等）。
　　交易模式 最著名的是MTS，它的英文全称是Microsoft Transaction Server，交易模式实现的功能非常多，比如，多段提交模式，其Pooling技术，也就是缓冲池技术，让数据提交更加安全、快速。很难想像，如果没有交易模式，三层结构要做什么：你要自己动手写大量的代码实现事务机制，如果解决得不好，还降低了程序的可靠性与速度。而MTS是建立在系统层的，可以帮助你解决许多本应在程序里解决的东西。还有一点要记住，目前市面上Windows开发平台上，只有Delphi与VC才能真正发挥MTS的功能。 　　三层结构编程要点
　　对此笔者不想讲太多理论，只给大家一句经典名言，这句话每个程序员都应该牢牢记住：All business logic in the Middle Tier（所有的商业逻辑处在中间层上）。如果不这样，你开发的三层结构程序就不专业，或者只是C/S模式的翻版产品。这句话虽然很简单，要达到这一境界却需要大量的经验积累。
　　另一个要领是: 一定要尽量减少应用服务器与前台程序的数据传递量以及Round Trip。因为如果你的三层结构存在频繁的Round Trip，那么你开发的应用服务器效率一定非常低下，当同时进入10个连接时，你就会发现应用服务器接近瘫痪。
　　在开发三层结构的系统时，应该养成一种好习惯，就是在系统分析或者设计报告中，较为详细地描述如何解决商业逻辑、如何有效降低数据传递量，以及只使用必要的Round Trip。只有这样，别人才能与你一起探讨你的解决方案是否合理，是否有更有效的实现方式。同时，经过不断归纳，提高自己的系统分析能力。
　　在开发大量用户连接的应用服务器时，多线程技术是必要的，否则当应用服务器在处理一个用户的请求时，另一用户只能等待，如果这种等待的时间太长了，用户就会对软件失去信心。还有一个是分布式的概念，你可以根据商业逻辑来切分，开发并发布多个应用服务器解决不同的商业逻辑；或者你可以将运行应用服务器的多个进程分布在不同的服务器中，并根据访问流程自动引导用户到合理的应用服务器中。
　　正是因为三层结构比C/S复杂，所以你要成为三层结构的高手，一定要经过一段较长的时间和大量项目的锻练。但三层结构体现了一个开发人员与系统人员的专业素质，因为它涉及太多东西: 技术工具的选型、模块化和组件化思想、前后台功能的分割等等。从真正意义上来讲，只有三层结构的项目才能完整反映软件项目的每个过程。
　　B/S模式与发展
　　主流的软件架构B/S与N Tier模式都有一些缺点，所以现在出现了许多B－N Tier的系统，就是基于Web浏览器的多层结构开发模式，它吸收了两者的优点。
　　我们知道单纯的B/S方式，虽然很令人兴奋，并且最终用户使用成本几乎为零，但它存在许多不足，它的功能较弱，无法非常容易地实现你的理念。比如你要实现一种商业模型，你会发现实际上Web方式是不安全、不可靠的，比如，用户可通过页面回退或前进来改变你所有希望的结果、报表制作能力不足等。
　　为什么Web会造成逻辑实现上的困难？因为它是基于Stateless（无状态）的。打个比方，Stateless就是这样一种情形：你与你的用户中间有一道墙，你并不知道墙另一边的用户长得什么样子，甚至是男是女你都不知道，然后你通过墙上的一个小窗递给他一件礼物，至于礼物最终的流向，你也一无所知，这就是Stateless。所有基于HTTP的东西都是Stateless的。而Socket的魅力就在于它是有状态的。
　　笔者以为现在发展起来的ASP、JSP、Java技术，都是在弥补HTTP协议存在的无状态缺陷，但即使有了这些工具，仍会觉得网页编程无法随心所欲，因为这些技术再先进，也无法解决HTTP协议基于Stateless的事实。
　　也许有人会问，这些动态网页开发技术是如何在一定程度上避免了Stateless的弊端的？以基于IIS的ASP技术来说，它使用Session变量来实现State。但是不管什么技术，最终都落在了COOKIE上，也就是使用COOKIE来保留客户端状态。
　　这里还要提一下Socket。Socket目前应用十分广泛，ICQ、QQ等即时通讯软件，还有许多网络工具，大都基于Socket，因为Socket协议是有状态的，所以才能做到这一点。可以这么说，是Socket让网络生活更精彩！
　　目前基于Web的多层结构采用的底层技术主要有SOAP＋State类协议或者HTTP＋State类协议。这里有一个Delphi程序员的好消息，从Delphi 6开始引入WebSnap包（一种Web Provider产品），它的设计者被Borland公司称为Borland历史上最伟大的工程师之一。它同时支持HTTP与SOAP协议，也采用了一种类似Session变量的模式来实现有状态(State)。它可以说是目前市面上最强大的基于平台的Browse/Server开发工具之一，其不足是它还不能称为完全的RAD工具，而且门槛较高。为什么不是ASP或者ASP.NET呢？笔者认为ASP不是基于平台的，它是基于脚本语言的，它的运行效率不高，而且它的调试困难。在Delphi 7中还引入了IntraWeb控件包，笔者以为它是一种真正意义上的网页RAD开发工具，与WebSnap配合更会如虎添翼。
　　Web Provider、逻辑组件、多线程处理、交易机制、消息流转等组合在一起是N Tier开发的最高境界，笔者以为是大型商业软件架构的首选。笔者在前面很少提到消息机制，主要是怕大家混淆了概念，消息机制并不一定在所有的多层结构中都存在，而且，如果要实现消息机制，必须寻找实现手段（比如使用Socket），否则，如果在程序中强制实施大量消息流转（比如使用定时器监控和消息数据表方式），无论是效率还是实现的复杂性来讲都是要考虑的问题。
　　软件开发人员的选择
　　笔者愿意把软件设计看成音乐艺术，它有许多流派，也有主流，但并不意味着别的思想被彻底抛弃。比如单层结构或C/S方式，许多人仍然在用，而且很擅长。笔者不鼓励读者抛弃这些传统的东西，笔者的意思是要扩大眼界，开放思想。而多层反映的是一种集成的思想，以安全、高效、图形方式整合系统，以组件思想逐步构架整个公司的商业逻辑，并降低最终用户使用成本。其最核心的思想是集中，所有中间层是集中的，可以在不同的服务器上运行不同的商业逻辑组件（比如.NET），但这个逻辑组件一定是提供给所有前端程序使用的。现在许多企业都在走系统集中的道路，集中可以带来无限的好处，但没有软件平台的支撑，集中是非常肤浅的。我们追求的不单纯是机器的集中，机器的集中会同时带来网络带宽的压力，只有应用集中了，才能最终达到合理配置资源的目的，这也是为什么我们要用多层体系、要用分布式思想来构建企业应用的真正原因。
　　笔者以为，在软件开发的今天，作为一名专业人员，如果总在单层或C/S构架下，永远形成不了系统思想，只有多层体系才能真正体会软件生命周期的理念，从需求分析形成商业逻辑到系统设计、数据库结构设计、组件化程序编写、测试、推广，一个好的N Tier系统一定要踏实地做好各个阶段的工作。这不像程序语言的变化或者开发环境的简单变换，因为它是一种开发思想与开发模式的完全变革，所以它也一定是一个过程，不可能要求自己在一两个月内就能真正体会并开始驾驭N Tier模式，但商业模式变了，开发思想也要变，你必须也只能让自己去适应新的思想，才能成为一名更加专业的开发人员。一旦你进入了N Tier的殿堂，并熟练掌握了这种开发模式，就会发现你开始逐渐形成了软件开发的系统思想，并且在这个领域上越走越在前面，开发也会越来越有激情。
　　编后语：可怜的程序员
　　“真累！”时常听到软件开发人员这么说。软件开发是一个高强度的工作，这是共识，无论对于体力还是脑力都是一个考验，因此不少程序员常常自嘲为“吃青春饭”的人。本人此前也做过几年软件开发，我也深谙其中的辛苦。我知道，对于软件开发人员而言，赶工期、赶进度、封闭开发、长时间的加班加点等很多人已经习以为常，不过和心理上承受的压力相比, 这点痛实在算不得什么，软件技术的更新日新月异，要在这一行立足，就必须时刻追踪技术发展，不然掉队事小，掉饭碗事大。C/S模式刚刚掌握，又流行起B/S架构，对高深莫测的J2EE、CORBA还是一知半解，.NET又接踵而至。掌握VB太基础，掌握Delphi也才刚刚跨入程序员大门。要想待遇高，那得掌握VC或者BC，若论工作机会多还数Java迷。最近又流行Web Services，也一定要弄明白，但要真正理解Web服务，掌握XML是前提。头儿有一天谈到UML，也要补上……“可怜的程序员，何时是尽头！”
　　作为程序员的你是否在工作中陷入过这个误区，也为此苦恼过？或许你已经走出了这个阴影，或许你对此能轻松对付，你是否愿意让大家分享你的经验和观点，无论如何，如果你对这个话题感兴趣，欢迎你和大家一起来讨论。
&&&主编推荐
H3C认证Java认证Oracle认证
基础英语软考英语项目管理英语职场英语
.NETPowerBuilderWeb开发游戏开发Perl
二级模拟试题一级模拟试题一级考试经验四级考试资料
港口与航道工程建设工程法规及相关知识建设工程经济考试大纲矿业工程市政公用工程通信与广电工程
操作系统汇编语言计算机系统结构人工智能数据库系统微机与接口
软件测试软件外包系统分析与建模敏捷开发
法律法规历年试题软考英语网络管理员系统架构设计师信息系统监理师
高级通信工程师考试大纲设备环境综合能力
路由技术网络存储无线网络网络设备
CPMP考试prince2认证项目范围管理项目配置管理项目管理案例项目经理项目干系人管理
Powerpoint教程WPS教程
电子政务客户关系管理首席信息官办公自动化大数据
职称考试题目
就业指导签约违约职业测评
招生信息考研政治
网络安全安全设置工具使用手机安全
3DMax教程Flash教程CorelDraw教程Director教程
Dreamwaver教程HTML教程网站策划网站运营Frontpage教程
生物识别传感器物联网传输层物联网前沿技术物联网案例分析
互联网电信IT业界IT生活
Java核心技术J2ME教程
Linux系统管理Linux编程Linux安全AIX教程
Windows系统管理Windows教程Windows网络管理Windows故障
组织运营财务资本
视频播放文件压缩杀毒软件输入法微博
数据库开发Sybase数据库Informix数据库
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&软件工程03 结构化分析_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
软件工程03 结构化分析
上传于||文档简介
&&同​系​列​的
大小：848.50KB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢提问回答都赚钱
> 问题详情
下面不属于软件工程3个要素的是(2)。不属于结构化方法划分的软件生存周期的三个大的阶段是(3)。A．
悬赏：0&&答案豆&&&&提问人：匿名网友&&&&提问收益：0.00答案豆&&&&&&
下面不属于软件工程3个要素的是(2)。不属于结构化方法划分的软件生存周期的三个大的阶段是(3)。A．工具B．过程C．方法D．环境请帮忙给出正确答案和分析，谢谢！
权威推荐： & &
发布时间：&&截止时间：
网友回答&(共0条)
回答悬赏问题预计能赚取&4.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&2.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&2.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&91.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&91.00元收益
回答悬赏问题预计能赚取&4.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&4.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&91.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&51.00元收益
回答悬赏问题预计能赚取&51.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&22.00元收益
回答悬赏问题预计能赚取&22.00元收益
回答悬赏问题预计能赚取&2.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&1.00元收益
回答悬赏问题预计能赚取&3.00元收益
回答悬赏问题预计能赚取&1.00元收益
你可能喜欢的
[] [] [] [] [] [] [] [] [] [] [] []
请先输入下方的验证码查看最佳答案
图形验证：
手机号码：您所在的位置： &
层次化软件体系结构
层次化软件体系结构
「美」Cal Henderson,徐宁译
电子工业出版社博文视点
《构建可扩展的Web站点》主要介绍了Web应用程序的概念、体系结构、硬件需求、开发环境的原则及国际化、本地化和Unicode等基本内容，本文是层次化软件体系结构。
第2章 Web应用程序体系结构Web Application Architecture
如果你已经准备好开始编码了，快些打开一个文本编辑器，并开始学习……但还请稍等。在你开始编码之前，我们想先考虑一下应用程序总的体系结构，并且做一些规划。所以请你把PowerBook暂时放在一边，去找一块大的白板和一些马克笔，定上一份披萨，再把工程师们召集在一起，准备讨论。
规划时应看一些适用于Web应用程序开发的、通用的软件设计原则，并了解如何用它们来解决实际问题。还要看看如何设计、规划和管理Web应用程序的硬件平台，以及它们在进行软件设计和开发时扮演的角色。在本章结束时，我们就应该准备整合环境，可以开始编写代码了。但在这之前，请先允许我讲一个故事……
层次化软件体系结构Layered Software Architecture一个好的Web应用程序看起来应该像一块蛋糕，如图2-1所示。
事情总是先苦后甜的，所以请暂且容忍我偏离一下主题。需要注意的是这里将提到的蛋糕是英式蛋糕，而不是仅有一层的加拿大蛋糕――相信接下来你很快就能明白其中的区别。但若是你对蛋糕完全没有概念也不要紧，只要记住蛋糕是种有多个层次的甜点就够了。蛋糕底部是一层较为坚实的、类似海绵的部分。其他各层都放在这层“海绵”之上。若是没有了这一层海绵，也就不存在所谓的蛋糕了。海绵层支撑着蛋糕上所有的其他部分，进而构成了这道甜点真正的内核。海绵部分一般较大，且结实可靠，而之上蛋糕的其他部分则是短暂而易变的。
在Web系统中，持久化存储层恰似蛋糕中的海绵层。存储数据的方式多种多样――可能以硬盘上文件的形式出现，也可能就是数据库中的记录。但它却体现了我们最为重要的资产――数据。在对其进行访问、操作或显示之前，这些数据总要有个安身之所。因此数据的存储也就成为应用程序中最重要的基石。&
图2-1：一个层次分明的蛋糕 （minky sue摄影：）
位于海绵之上的就是至关重要的果冻（Jelly）层（对北美读者而言，则是Jell-O）。每个蛋糕都有海绵层，这一层虽然很重要，但各个蛋糕的海绵都一样。只有通过果冻层才能体现蛋糕的独有特性。用户/用餐者只能通过果冻层来和海绵蛋糕层交互/食用海绵蛋糕。果冻不仅仅体现了我们蛋糕独一无二的主要特性，而且是对底部海绵层访问的必经途径。果冻层和海绵层一起才定义了什么是一个真正的蛋糕。而其他添加于这两层之上的，都是关于交互和外观的内容。
在Web系统中，我们的业务逻辑负责扮演果冻层。就像果冻层的作用一样，业务逻辑体现了我们系统与其他系统的区别和我们系统的独特之处。访问和操作数据的方式方法定义了系统的行为及所需遵循的规则。而访问系统数据的惟一途径就是通过业务逻辑。如果我们除了持久化存储和一些业务逻辑之外什么也不添加，系统也已经具备了核心功能，但没有哪位客户会愿意食用/使用它。很久以前，业务逻辑总是用C或COBOL来实现（没开玩笑）如今，只有大型系统（性能攸关）和遗留系统（修改成本过高）才采用这种方式。现在，使用你所偏爱的脚本（PHP、Perl、Python、Ruby等等），或者选择使用较为友好的Java语言来实现业务逻辑是完全可行的。
至此我们有了作为支撑的海绵层和体现个性的果冻层（上面或许还有小块水果，在分层系统中找不到能和这些水果类比的有意义的事物。但不管怎样，它们也是蛋糕的有效组成部分）。现在也许可以宣称我们有了一个甜点，是的，这个甜点正逐渐成形，但是却还不能被称为一个蛋糕。下一步我们还需要奶油冻。将奶油冻涂抹在果冻上，对用餐者而言，奶油冻是和处于它下面的层次的分界面。奶油冻并不是系统的基石。实际上，只要有必要，我们完全可以将它去掉。事实上，我就曾经烤制过极差的奶油冻（烧过头的牛奶实在糟透了），但直到我将它倒在果冻上后，才真正意识到它是多么的讨厌。这可真是个大错误，好在我可以将它刮掉重做。最后的蛋糕还挺不错。所以说，奶油冻本质上是可以被替换的。
在Web应用中，与奶油冻相对应的是我们的页面和交互逻辑。业务逻辑这个果冻层定义了如何访问、操作和存储数据，但没有规定数据应该一起被展示，也没有规定修改数据的具体流程。这些事是交给页面逻辑来做的，页面逻辑告诉用户需要经过哪些沟沟坎坎才能完成目标。页面逻辑和交互逻辑是可被替换的，替换它们不会影响到应用程序的功能。而且如果你在业务逻辑层之上构建了一系列的API（具体方法将在第12章中详细探讨），那么完全可能在业务逻辑层之上建立多个交互逻辑层。这里无法继续用蛋糕作类比了（到了某个时候，这终归是无法避免的），但我们仍然可以尝试着想象有这样一个蛋糕，它有着巨大的海绵层和果冻层，上面的多个不同区域中都有另外的层次。也就是说，底部层次可以支持多个交互层，只要将它们建立在不变的底部基石之上。
挑剔的观察者或厨师会注意到我们的甜点还不算完整――至少还需要一层，而如果要和Web系统进行类比，那么至少还需要两层。紧随奶油冻之后的层次就是乳酪，你是不可能只有奶油冻而没有乳酪的；这两样在蛋糕中是一体的。仅有奶油冻的蛋糕对普通用餐者而言是难以接受的。虽然固执的厨师/开发者会认为没有乳酪的蛋糕也算蛋糕，但对用餐者/用户而言那就是一团糟。因为我们总需要某种途径（比如乳酪）来将下层信息传达给我们的用餐者/用户。
在Web应用中，乳酪对应的是Web上的标记、桌面上的用户界面工具集和应用程序接口中的XML。标记层给人们提供访问底部层次的方法，进而给用户提供处在标记层之下层次的相关印象。单是乳酪本身无法成为一个蛋糕，甚至相对蛋糕本身来说它也不能算是蛋糕的一个重要组成，话虽如此，但天生我才必有用，它的重要用途就是告诉普通观察者这是一个蛋糕。与之相类似的，标记也用于和用户交换数据，并将交互概念传达给用户。稍微偏离一下蛋糕这个话题，浏览器和其他用户访问引擎可以由我们用户的嘴巴和味蕾来扮演，嘴巴和味蕾将食物转换为对用餐者有意义的各种感觉，而浏览器等则将我们的层次变成对用户有意义的内容。
撇开盛放蛋糕的器皿（市场部）和用餐者（用户）不谈，现在已经是万事俱备，只欠东风了。由于现在蛋糕已经具备了所有必要部分，开发者可能已经很满足而止步不前了，但是一个普通用户却会令人出乎意料地关心其表现形式。因此，在我们层次分明的杰作之上，还需要用水果、碎糖粒或者其他美妙诱人的东西来装饰和点缀。这些装饰物的主要作用，就是让其下的层次显得漂亮。漂亮的蛋糕更加易于被人们接受和承认，也能使他们食欲大增（前提是这些点缀摆设一定要好看，否则就可能有相反的效果）。
被我们比作点缀的是展现层，展现层位于我们的代码和工程学形成的杰作之上。就Web页面而言，展现层是一个由标记、级联样式表和图形（有时还有脚本化的窗口部件，如果我们不将它们归为标记一类的话）所组成的领域；对基于API的应用程序而言，展现层与上述相同；对于电子邮件，上述内容则无需存在（除非你正在发送HTML邮件，这时它的展现层和普通Web页面没什么两样）。
总之，我们想说明什么呢？一个好的Web应用有许多的层次，每一层都有其独立的功能，所有这些层次通力合作，构建起一个系统，但假如你尝试着随意组合它们，你只能得到一个劣质的系统或者说一个什么也不是的大杂烩。从开发人员/厨师的角度来考虑，自然是最底层最重要，因为它是整个上层结构的基石，支撑着我们的系统。而从用餐者/用户的角度来看，却是比较高的层次更为重要，因为它们才是甜点的亮点，用餐者/用户会将底层视作理所当然的存在，尤其是最底层。因为对用户而言，这些底部层次自然而然的就应该是Web应用的一部分。待会儿我们还会看看这些层次相互之间如何进行交互。（不幸的是，我们还无法像蛋糕一样，只要依靠重力来维持它的稳定，因为我们要的是一个经得起折腾的系统），下面我们会阅读一些案例，来看看这些层次如何各司其职。【责任编辑： TEL：（010）】&&&&&&
关于&&&&&&的更多文章
XML 全称是“可扩展标识语言“（Extensible Markup Language），
本书描述了黑客用默默无闻的行动为数字世界照亮了一条道路的故事。
讲师： 5人学习过讲师： 5人学习过讲师： 8人学习过
MATLAB 是数值计算、可视化及编程的一种高级语言和互
《2016年全国会计专业技术资格考试辅导教材 初级会计
《21天学通Visual C++（第4版）》共21章，从Visual C+
本书是针对全国计算机技术与软件专业技术资格（水平）考试而编写的，书中详尽分析与解答了2006年上半年的程序员级、软件设计师级
51CTO旗下网站