英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料
使用模型(model)－视图(view)－控制器（Controller）设计模式开发Web应用
摘要：
对于构建交互软件系统来说，模型-视图-控制器设计模式是非常有用的，这种设计模式是分层的，因为它表示为在单个中运行的交互式应用程序的术语地址空间。应用模型-视图-控制器设计模式到web应用程序如此复杂，事实上目前的技术鼓励开发人员在设计阶段尽早对应用程序进行分层，对该分层的后续更改要求对应用程序实现的重大更改--尽管应用程序逻辑没有改变.这篇论文介绍了灵活Web应用程序分层的概念、编程模型和实现基础结构,允许开发人员将模型-视图-控制器设计模式应用于独立分层，应用开发并在单个地址空间中进行测试;在不更改应用源代码的前提下，他们可以部署到不同的客户端/服务器体系结构中。另外，在不用修改应用的情况下分层决策也可以被修改。
1介绍
-
- 模型-视图-控制器设计模式
众所周知的模型(model)－视图(view)－控制器（Controller）（或MVC）设计模式是构建交互式软件系统的一种有效方式。也被称为表示（Presentation）-抽象（Abstraction）-控制（Control）（或PAC）设计模式。它的要点是将用户界面与通过用户界面呈现的底层数据相分离。典型的MVC设计模式事实上已经应用在了低端的用户交互中，比如单个按键或者鼠标按钮的激活。在MVC模式中，视图将信息展示给用户，并且和负责处理用户交互的控制器一同构成了应用的用户结构。模型是应用程序的一部分，它包含了视图所要呈现的信息和针对用户交互修改信息响应的逻辑。PAC设计模式类似地对用户界面中的应用程序信息进行了分离。MVC的视图和控制器被组合成一个演示文稿;应用程序的数据称为抽象组件，控制组件负责抽象组件和具体展示的耦合。MVC和PAC设计模式的使用使开发和维护应用程序变得更容易,因为:
·不需要更改数据结构和业务逻辑，应用程序的'外观'就可以被彻底改变
·应用程序可以轻松地维护不同的接口, 如多种编程语言或不同的用户权限集
通俗来说。术语“MVC”被扩展到用来描述大规模变化的方式，应用程序的模型由一个控制器来驱动，不仅负责接受和处理用户交互，还要改变应用程序的逻辑状态以响应应用户创建的事件来进行交互。为了响应模型的变化，控制器启动创建应用程序的新视图。本文使用术语MVC，更普遍和“类似PAC”，构建一个应用程序来将它们的业务逻辑，表示逻辑和请求处理进行分离。
-
- 网页应用和MVC设计模式
网页应用，像其它交互软件系统一样，可以通过使用MVC设计模式构建来获得优势。比如说，一个全部使用java实现的方式，它使用EJB作为模型，通过HTML和JavaServer Pages构成了视图，并且使用Servlet和Session EJB来实现控制器。
使用MVC设计模式来开发网页应用的问题来自网页应用本质要求客户和服务器分离的现实。当然，视图是在客户端展示的，但是模型和控制器（理论上来说）可以通过各种方式在客户端和服务器端进行分离。开发者不得不在实现阶段将网页应用的up-font分层。相反，MVC是分层的：比如，模型，视图和控制器驻留和执行在单一地址空间的分区问题不会出现。由于位置独立问题不应该影响架构或者设计决策，所以分层独立是MVC的一个特色。不幸的的是，分层意味着网页应用程序是依赖位置的，这个特点意味着在网页应用情景中应用MVC模式更加困难。
当然，开发人员可以简单地对Web应用程序进行分层，然后将方法A将在服务器上运行，方法B在客户端上运行。分层完成后，MVC设计模式可并行应用于实现应用程序的客户端和服务器部分。这种方法的问题在于，通常是不可能在设计的早期做出正确的分层决策，因为这些决策取决于在整个过程中发生不断变化的应用需求。当面临正确分层决策以来静态（比如客户端到服务器的相对功率）和动态（比如网络拥塞）环境因素时，问题将变得更加复杂。应用MVC设计模式在一个分层决策不固定的环境中是一个艰巨的任务。
更糟糕的是，“控制器层”通常不是一个开发过程中独立的，“可调用”的特征。除了是网页应用内在特征的一个功能外，分层还取决于和应用无关的技术决策。举个例子，就拿“精简客户端”与“臃肿客户端”来说，通常应用程序开发人员在选择实现技术时会受到限制，也许他们被告知“applet是坏的，因为他们是臃肿的，而且还有安全问题”。也许他们被告知“你不能在HTML中构建复杂的视图”。一旦技术选择做出，他们就会完成很大程度上决定了应用程序将如何分层。使用精简客户端部署时，只有网页应用程序视图驻留在客户端;控制器（不包括实际的窗口屏幕控件）和模型都驻留在服务器上。当使用臃肿客户端部署时，Web应用程序的模型和控制器都驻留在客户端。换句话说，技术选择意味着开发者也许不能做出正确的分层决策-即使他们知道正确决策是什么。
总结一下，当属于以下情况时，网页应用程序可以确定使用MVC设计模式:
·知道正确的分层
·掌握的技术基础和分层是相兼容的
实际上,开发人员通过对技术和分区解决方案进行先验假设来简化问题。此方法之后将更详细地讨论(3.2.3节)
我们介绍了灵活进行网页应用分层（或fwap）的概念(或 f w p) 使 web 应用程序能够更自然地使用MVC设计模式。除了讨论fwap和其他相关工作,在3节中, 我们首先看一下在2节中网页应用程序分层的一个简单的正面示例
2对一个网页应用进行分层：示例
图中的网页应用可以让客户得到一个公司雇员的信息，我们通过让客户只执行两个操作来简化示例。
1通过提供一个名字，然后点击“搜索”按钮，按照名字来搜索雇员。对于反馈的每个记录，搜索将用展示雇员记录缩写格式的方法来返回匹配搜索标准的一系列雇员记录。
2通过点击“详细？”按钮，得到一个特定雇员的详细信息
从MVC设计模式的角度来看（见图一），在一个单一简单的环境中实现是很简单的。
· 模型由雇员目录的记录构成
·这里有四个视图：一个“搜索”框；一组雇员记录缩写的展示，一个展示特定员工详细信息的展示以及一个没有员工符合搜索条件的报告。
·这里有两个控制器：一个给定一个'搜索' 指令, 驱动模型的查询并返回结果集;另一个给一个'详细信息'指令,让查询模型获取详细的有关指定员工的信息。
然而，一个网页应用程序在客户端/服务器端环境下的实现引发了在概念上与MVC设计模式矛盾的分层问题，实际上使MVC设计模式更加复杂化。因为有了两个控制器，应用程序可以通过四种方式中的任意一种实现。两个控制器都在客户端或者服务器端运行，或者一个在客户端运行，一个在服务器端运行。每个分层决策都会影响应用实现的方式。举例来说，如果两个控制器都运行在
客户端 ('臃肿客户端' 方法), 整个模型必须下载到客户端-这通常是不切实际的。如果两个控制器在服务器上运行 ('精简客户端'方法), 每次客户端和服务器之间必须执行两轮往返当客户端搜索雇员信息, 然后要求更多关于雇员的细节。
事实上，对于很多环境，无论是精简客户端还是胖客户端都是理想的。相反，我们使用双mvc方法在控制器和客户端之间进行分层。具体来说，“搜索”控制器与服务器上的模型组合在一起执行完整的雇员目录。但是，当返回相对较小的雇员记录集合时，控制器还会返回每个雇员记录的完整记录，以便他们可以保持在客户端模型中。dual-mvc方法允许客户端来处理详细的雇员记录的请求，从而消除了客户端/服务器的交互。（这种实现只在应用场景中有用
通常包括对员工的初步搜索，使用“部分姓名”，然后在特定雇员被确定后请求更多信息。记住：这只是一个正面的例子！）。
当然，我们真正想要的是在实现应用程序时避免分层，因为正确的分层决策只有在实际部署的时候才能够决定。例如，如果员工目录相对较小，那么两个控制器都在执行的“fat client”方法很有意义并且会提供更好的性能。相反，如果应用程序部署在“互联网”环境中，用户想要最小定制的环境，“thin client”的做法可能是唯一可能的解决方案。尽可能减少应用程序分层更具吸引力，因为分层妨碍了设计视图和开发控制器所需的业务逻辑。灵活的Web应用程序分层解决了这些需求。事实上，灵活的网络应用程序分层进一步允许分区决策在应用程序执行期间动态变化。
fwap编程模型明确支持MVC设计模式，并且可以让程序在smvc模式（第3.1节）下的单个地址空间中执行。当部署的时候，使用smvc开发，这些程序可以灵活地进行分层而不更改在此期间使用的源代码。我们将这种fwap应用称为fwaplication。
3灵活的网页分层
尽管网页应用必须处理分层问题，第二节阐述了为什么最好用分层的方式来实现网页应用程序。分层独立使开发者能够更灵活地分区，因为它使他们能够处理不断变化的技术基础设施，改变应用特性，甚至是改变网络拥塞等环境条件。当然，问题在于如何保持分层的独立性，因为网页应用是位置依赖的。Fwap编程模型的实现和基础架构使开发者能够正确地以分层独立的方式来搭建网页应用。应用在单一地址空间中被开发和测试，不用修改应用的源代码，它们可以被部署到各种客户/服务器架构。除此之外，不用修改应用就可以改变分层决策。
为了提供分层的独立性，fwap必须解决一系列难题。这些问题包括针对应用程序的单个模型、视图和控制器组件分层的技术;将这些组件集成在一个统一的应用程序模型中，构建将一个应用程序分层独立的表示形式映射到运行在实际的客户端/服务器平台上的分层应用。我们目前专注于 让fwap可以支持各种部署体系结构。为了取得进展, 在这方面, 我们已经作出了一些简化假设，这使我们可以避免上述一些问题.我们讨论以下假设 (3.2节)
3.1 fwap架构
fwap支持以下的架构：
single-mvc（或smvc），它以fwap开发架构运行。smvc体系结构对应传统的MVC设计模式（如图1所示）：模型，视图和控制器都在单一的地址空间驻留并执行，不会出现客户-服务器和分层问题。
thin-client,一种模型和控制器在服务器的单一地址空间驻留和
执行，并将生成的视图在客户端呈现的部署体系结构。
dual-mvc（或dmvc），一种客户端和服务器都有控制器和模型驻留的部属体系结构。只要需要，客户端和服务器都可以生成视图，并在客户端展示。
3.2 相关的工作
3.2.1. 视图规范和生成 为了将视图呈现在不同的客户端平台上，它们必须以独立于平台特性的方式来进行规范。一种解决这个问题的途径是使用XML来作为用户界面通用的，应用独立的标记性语言。我们方法的不同之处在于我们使用了一个Java API来规范用户的图形用户界面（GUI）组件库然后通过这些组件来构建视图。在运行的时候，特定平台的实现库来向客户设备呈现视图（比如：在网页浏览器上使用的HTML）。目前我们没有关注如何在有着不同因素的桌面和网页浏览器环境中呈现”规范”视图相关的问题（比如：掌上电脑和电话）
3.2.2. 控制器规范和执行 因为我们想让fwap应用可以在dual-mvc体系架构中部署，所以控制器必须能够在客户端和服务器上执行。由于我们将fwap应用的控制器编码到Java虚拟机中，因此这个将很多作为fwap应用的部署平台的客户端排除在外。比如，掌上电脑和网络电话可能不支持Java虚拟机，尽管我们希望J2ME后续能够让这些设备支持Java应用程序。即使在使用网页浏览器的情况下，设备对独立性的要求也表明使用JavaScript实现控制器比使用Java要好（比如：微软的IE和网景的Navigator）。目前，我们通过使用Java插件简化了单一来源的控制器规范，这将允许标准网页浏览器运行JDK1.2编写的应用程序。
3.2.3. 控制器规范和执行 值得注意的是现在很多项目都在使用模型-视图-控制器设计模式来开发网页应用。fwap的关键贡献是它对分层独立性的重视。相比之下，假设网页应用被部署在一个精简客户端体系架构中，那么其它努力都是层次依赖的。
在接下来的文章中的展示框架都正在被开发中。在上个世纪90年代推出的Java Servlet技术推动了一种风格的网页应用程序设计，在Servlet代码中生成的视图通过一系列的println语句，把HTML语句写到客户端的网页浏览器。1999年JavaServer Page技术的出现，允许开发人员将这种模式颠倒过来嵌入脚本代码（用来访问服务器端的模型和控制器代码）到HTML页面。这两个方法都违反了MVC设计模式，因为它们往往将视图代码和控制器，模型代码混合在一起。 精简客户端展示框架正在开发中，目的是更方便地使用MVC设计模式来构建网页应用。它的基本思想是利用Servlet和服务器端的JavaBeans作为应用的控制器（应用逻辑）。使用EJB来表示模型和业务逻辑;并使用JavaServer Pages来提取模型数据和生成视图。有些框架强调不同的主题，因此，Barracuda使用“推送MVC”的方法，其中模型负责生成视图; WebWork和Struts使用“拉” MVC“方法，其中视图根据需要访问模型。 Struts比WebWork
全文共14164字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[13982]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
