MVC模式与MVP模式的不同
摘要：Web应用程序框架是通过不同的设计策略进行管理的。设计策略被不同的设计工程应用。在不同的设计工程中，需求规格被改变成不同的设计模型，描述不同的数据结构，系统结构，接口和组件组建的细节。Web应用程序框架的工作是通过使用MVC和MVP来实施。这些Web应用程序模型被用于提供Web应用程序的标准化视图。本文主要针对MVC和MVP的不同的设计方面的比较。一般来说，我们根据MVC和MVP的实施情况、合适平台的实施情况和合适MVC和MVP的环境来提出不同的方法。
1.绪论
不同的建模技术被应用于不同类型的Web应用程序和每一个Web应用程序框架可能不同于其它的Web应用程序。建模技术帮助开发人员遵循一个合适的体系架构，这个架构根据企业用户的需求和Web应用程序的类型来选择。基本上，有两种建模技术被应用于Web应用程序框架工作，它们是MVC（Model-View-Controller）模式和MVP（Model-View-Presenter）模式。而且，企业级应用程序需要满足多类用户的不同的功能需求。不同的接口可以满足无线网，管理员，企业对企业用户和企业对消费者的需求，还能满足如HTML，XML，JFC等多种视图要求和不同的接口可以更新相同的企业数据。
在MVC模式中，应用程序或者应用程序的一部分被划分成模型、视图和控制器三个部分。MVC最初的开发人员映射传统的输入，处理，输出。
输入（Input）﹣﹣﹥处理（Processing）﹣﹣﹥输出（Output）
控制器（Controller）﹣﹣﹥模型（Model）﹣﹣﹥视图（View）
模型能用来处理企业数据，也能处理使用和更新这些数据的业务规则。模型负责实际数据的处理，例如数据库连接，查询数据库，实施业务规则。它提交给视图的数据没有考虑这些数据的表示和转型。通过MVC的模型层处理的数据是清晰明确的，所以这项技术有一个优势——同一数据可以连接多种视图而无需多余的代码。另外，基于同一数据的不同视图表示是彼此独立的和这些数据的变化是依赖于模型的。这样减少了代码的错误率和提高代码的重用性。当模型状态发生变化时，模型会通知视图以触发应用程序在视图中的变化。
控制器是用于捕获和封装用户的输入请求，然后选择并调用合适的模型。控制器还有一个任务是基于用户的输入和模型操作的结果选择下一个视图的显示。
图1 MVC模式各组件关系图
视图是数据的图形化表示，与真实数据的处理无关，它负责格式化和安排数据的表现形式。它的职责是显示数据，所以不需要考虑所有的操作例如数据库连接，查询数据库等。视图从模型中得到最终的数据，并将其显示到浏览器之前对数据进行重新排列。一般来说，视图的主要特征为有独立的平台，在分布式环境中工作良好。图2表示视图在系统中的角色。
在MVP模式中，模型组件与MVC相似。对于一个程序员，你不能在一个引用Presenter和视图的模型中有一个实例变量。在MVP模式中，视图了解Presenter，但是反过来不行。控制器在现在的MVP模式中被改变成Presenter。Presenter仅仅是负责与模型（Model）通信和改变用户界面元素。建模采用的方式是基于用户的基础设施和用户对它响应的方式。
图2 视图在系统中的角色
2.MVC和MVP体系架构的不同
软件基础架构的设计是一日一日改变的，它是基于优秀设计的评选标准来完善的。
·应用进程之间的数据流
·目标用户
图3 MVC和MVP组件的比较
MVP架构表明，视图不依赖于模型。相反，在MVC模式中我们有两次“读取数据的事件”。
·视图可以直接从模型中读取数据和声明与控件绑定的数据。
·模型发送数据给视图，视图再次重复同样的进程给控制器使得控制器得到数据。
大多数的数据更新条款是基于视图发送的更新的表单数据和控制器检查、更新数据。
A.视图的角色
视图在MVC中担当的角色与在MVP中担当的角色是很不同的。
·在MVP中，presenter直接与它对应的视图通信，并可以很容易地提供用户信息，相比之下特定的MVC模式的地方无法直接链接到其相关的视图。
·在MVP中可以很容易地为同一个presenter改变多类视图的作用。
·没有业务逻辑的实现在MVP中。
B.控制器的角色
MVC模式允许任意数量的控制器去处理视图，大多数在web应用中的视图可以处理不同的事件，按钮可以通过使用鼠标来访问，或集中，或使用enter键输入。因此，它是需要一些时间实现不同的操作侦听多个事件。
图4 展示试图和控制器之间的关联
C. Presenter的角色
Presenter是唯一可以从模型中读取和检索数据的。Presenter直接通过接口视图和视图进行通信。
D.模型的角色
在MVP和MVC中模型扮演着同样的角色，它包含逻辑数据和处理这些数据的方法函数。MVC和MVP之间的主要区别是：在MVC中，模型不仅捕捉工程与它的连接,而且了解工程怎么工作。两种不同的模型可以基于由不同的数据集进行不同的任务来创建。在MVP中，不允许为了更新与所述事件相关联的状态而与presenter保持直接的引用。在MVP中，视图了解模型，但是反过来，模型不知道视图。因此，除非我们刷新更新，否则网页无法适用MVP模式，但它可以在MVC架构的情况下进行更新。
3.MVP和MVC架构存在的问题
MVP架构在1990年推出，它的出现是为了克服MVC耦合的问题。因为模型，视图和控制器可以直接链接到对方，所以MVC是最适合的桌面应用程序。但是这种紧耦合在Web应用程序中会产生问题，使得多个视图可以更新控制器。这也是MVC处理视图逻辑和视图状态产生的困难。人们想到通过MVP移除这个依赖来解决这个问题，和需要开发一个presenter作为接口与视图连接。MVP成功地使用了三个步骤来解决这个问题。
·第一步，它将视图看作是一个组件,描述视图是如何处理表单和控制器UI的，视图的任务要求是用户必须在视图界面有输入但是它们很少与presenter直接相连接。
·在presenter之外，视图与模型直接相互影响。Presenter更新视图（监督控制器）。在presenter没有更新视图时，presenter比被动的视图需要更少的编码。
图5 MVP的角色（监督控制器）
·在MVP中有一个略微地变化，在MVP中的应用程序逻辑现在是视图的一部分，而且presenter在被动视图方面不能执行任何动作去与模型进行交互，因为这是用于测试驱动开发环境的主要设计。
但是在MVP中问题依旧没有解决，因为它很难实施而且presenter互相连接。模型没有意识到presenter在任何情况下被改变会触发被动视图。在不同层之间工作是十分困难的，并且管理不同的层需要较高的专业技术。
4.模型2（MVCII）
这种架构成功地克服了应用逻辑分离业务逻辑与紧耦合相关的问题。
·在MVCI中我们能够使用多个控制器来解决问题，但是现在我们只需要一个控制器就可以解决问题。现在，每一个类型的Web客户端可以发送来自单一URL的请求。
·视图组件的这种分离提供了Web应用程序日志记录的更多的安全性。
·在MVCI中
Web浏览器﹣﹣﹥JSP页面﹣﹣﹥Java beans
这可基于请求参数或由源文件通过超链接来确定。
但是在MVCII中
JSP﹤﹣﹣﹥控制器 servlet ﹤﹣﹣﹥浏览器
所以，现在的servlet发挥作用的应用程序并不直接链接到与JSP页面。现在的servlet处理整个HTTP请求。这种类型的设计模式如今是由Struts实现。
5.总结
MVC通常被小型应用程序采用，因为它容易被管理且有简单的导航。MVP被采用通常是用于测试驱动的开发和使用被动视图presenter对模型去耦合，但是它难以管理多个视图。MVC2的架构现在已经实现在应用程序可以有多个视图，有一个控制器，并使用可以在Java实现，以及.NET框架工作的不同的处理程序类。
Java Web服务的性能评价：
一个开发人员的角度
摘要：随着互联网的人口增长迅速，网络技术的发展变得非常重要。对于Web2.0的演变，Web服务是必不可少的。Web服务是一个允许不同平台的计算机在网络上交互式通信的程序，它不需要额外的数据来让人们读取接口和格式，例如Web网页架构。由于Web服务是因特网增长的未来趋势，所以被用于发展的工具也是很重要的。虽然有许多Web服务框架可供选择，开发者应该选择基于性能，时间和精力的，最适合他们的应用程序的框架。在这个项目中，我们选择了四种常见的框架，对他们定性和定量地进行比较。运行测试后，结果由SAS统计分析。
关键字： Web服务，框架，性能，Java，开发者
1.绪论
前往其它国家或者省市，人们通常需要购买机票，租一辆车和预订留宿的酒店。当购买飞机票时，大多数情况下人们不得不买几张转换站点的票，而不是直接将人送达目的地的票。我们需要花时间查找和计划飞行路程，根据飞机的到达和起飞时间来连接下一个可能的航班。假如有一个虚拟代理可以做到这一切在短短的几秒钟内呢？所以，通常人们会寻找代理为他们做这些。但是，如果这个代理实际上是一个虚拟的网上代理。如果有人只是向电脑输入他想要开始的位置、目的地、想要出发和到达的时间和所有的信息要求，马上电脑就向你显示所有的结果，来供你选择买哪类票。更好的是，这样的虚拟代理也有可能向你提供目的地的汽车租赁和酒店住房信息并为你预订它们。通过使用这类虚拟代理，可以节省大量的精力和时间，更可以说是比人类更准确。这种技术依赖于Web服务的开发和广泛流传。
除了从scratch中开发Web服务应用程序外，这里还有很多开源框架，使开发变得更加容易。这些框架将会是Web服务应用程序开发的一个更好的选择吗？这项研究定性和定量地通过多次测试和分析比较了四种流行开源框架。这四个框架是Apache Axis, JBossWS, XFire,和Hessian。介绍更多Web服务在第2节。第3节介绍这四个框架的研究。在第4节，对用于测量框架的指标进行更详细的解释。第5节介绍了用来分析测得的结果的统计分析方法。在第6节展示和分析实验结果。得出的结论在第7节。
2.Web服务框架
由于Web服务传输数据的方式被设计成常见的方式，所以有几家公司和集团为了Web服务开发人员的方便使用Web服务框架，这样他们就不必从scratch中编写一个完整的Web服务程序。一些流行的框架，例如Apache Axis, JBossWS, Codehaus XFire, 和Caucho Hessian。在这一节中，这些框架都将会被介绍。
2.1.Apache Axis框架
Apache Axis (Apache Extensible Interaction System)是由Apache软件基金会（ASF）创建的一个开源的，基于Java和XML的Web服务框架。该基金会是一个非营利性组织，它主要生产用于网络用途的软件，例如服务器和用于服务器框架。众所周知，它们的项目是基于发展的进程和免费或开源的软件。Apache Axis包有一个SOAP服务器和API用于产生和执行Web服务应用程序。SOAP的引擎构造使SOAP处理器像客户端，服务器和网关。这使得服务器和客户端通过SOAP消息进行通信。该API支持各种语言。除了Java版本，C 也是可以被使用。它允许开发者以多种的形式去构造他们的应用。最简单的方法只需要改变文件扩展名，从“.java”变成“.jws”。这种方法的缺点是为进一步的配置缺乏灵活性。
2.2.JBossWS 框架
JBossWS是实现J2EE兼容的Web服务。该框架的设计更适合整个JBoss架构，而且通常更适合满足特殊的J2EE的Web服务要求。而不是对这种框架使用传统的Apache服务器，JBoss有自己的一个服务器，并且建议在框架上使用该服务器，这是为了获得最佳的性能。类似于ASF, 这是一组专注于开源项目的人在JBoss社区。他们的项目强调了Java企业级开发，这些软件像桥梁连接应用和操作系统之间。
2.3.Codehaus XFire框架
Codehaus XFire是下一代java 的SOAP框架。它是一个自由和开源的SOAP框架，允许人们可以非常方便和简单实现Web服务。在Web服务规范中，它还提供了许多识别特征，但是还没有在大多数的商业或开源工具使用。它声称拥有更高的性能，因为它是建立在低内存StAX (Streaming API for XML)中的。StAX虽然基于模型但实际上没有数据的计算。
3.4.Hessian框架
Hessian二进制Web服务协议使开发Web服务简单实用而不需要大的框架，所以开发人员并不需要花费许多时间和精力来学习协议的专用术语。由于它是一个二进制协议，且在发送二进制数据时运作良好，所以不需要附件的扩展协议。J2ME设备像掌上手机使用Hessia
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[152670]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
