英语原文共 6 页，剩余内容已隐藏，支付完成后下载完整资料
ASP.NET和JSP框架中模型-视图-控制的实现
摘要
模型-视图-控制（MVC）是为了隔离用户接口逻辑和业务逻辑的基本设计模式。模型-视图-控制（MVC）模式是一种排序方法并应用到三个不同的组件：模型层，视图层和控制层。在本文中，我们在两个不同的框架中实现MVC方法；ASP.Net框架和Java Server Pages（JSP）框架。在这项研究中，我们的研究结果显示ASP.Net框架比JSP框架更容易实现MVC的主要概念。
关键词：应用服务器，ASP.Net，控制器，JSP，Model，MVC，鲁棒性分析，UML，View。
1.介绍
万维网的发展速度越来越快，越来越多的政府和非政府组织机构，私营公司，大学和研究机构将其内容发布在互联网上。将用户的接口逻辑和业务逻辑分开是非常困难的。模型-视图-控制（MVC）模式是一种排序方法并应用到三个不同的组件：模型层，视图层和控制层。使用静态HTML页面完成此操作是非常困难的。为了能轻松分离用户接口逻辑和业务逻辑，我们需要一些技术来连接用户接口到Web并动态地呈现内容。有很多不同的技术可用于将用户界面连接到Web，但这些技术都有一些优点和一些缺点。在一个具体环境下，很难决定一个特定问题的解决方案。在本文中，我们描述和探索在两种不同构架（ASP.Net框架和Java Server页面（JSP）框架）中实现MVC方法的最重要的技术：Active Server Pages（ASP）和Java Server页面（JSP）。但是，这似乎是一个有一些重大的问题的自然的方法。一个问题是用户接口比数据存储系统变化更频繁。另一个有关耦合数据和用户接口件的问题是企业应用程序倾向于合并业务逻辑并远远超出数据传输。因此，主要的问题就是如何模块化Web应用的用户界面功能从而可以轻松地修改程序独立的部分？在这种情况下，有一些措施可以对系统展开应用，并需要好好地考虑解决问题的方法[2,3,4,5]。
*用户界面逻辑变化比业务逻辑变化更频繁，特别是在基于Web的应用程序中。这些变化导致了获取错误，在每一个微小的用户界面更改后需要重新测试业务逻辑。
*在某些情况下，应用程序以不同的方式展示相同的数据，特别是使用电子表格时并以分析为目的。在一些丰富的客户端用户界面，同样的数据的多视图查看在同时显示。如果用户在一个视图中更改数据，系统必须全部更新其他视图中的数据。
*用户界面活动一般由两部分组成：演示和更新。演示部分检索来自数据源的数据并为了展示格式化数据。当用户基于数据执行动作，更新部分将控制权交回业务逻辑来更新数据。
*为用户创建自动测试界面一般比较困难，而且比业务逻辑更耗时。因此，减少直接绑定到用户的代码量，界面增强了可测试性应用程序。
解决方案是使用模型-视图-控制（MVC）。模型-视图-控制（MVC）适合划分域，展示和基于用户输入的行为的模型，用户输入的行为分为三个不同的类，如图1所示：
*模型：模型管理应用程序域的行为和数据，响应请求有关其状态的信息（通常从视图），并回应改变状态的指示（通常从控制器）。
*视图：视图管理信息的显示。
*控制器：控制器解释来自用户鼠标和键盘的输入，通知模型和/或视图进行合适地更改。
图1：MVC类结构
注意视图和依赖于模型的视图控制器是重要的。但是，模型不仅取决于视图也取决于控制器。这是分离的主要好处之一。这个分离允许模型的建立和独立的视觉呈现测试。在许多丰富-客户端应用程序中，视图和控制层之间的分离是次要的。实际上，很多用户接口框架实现角色为目的。在Web应用程序中，另一方面，视图（浏览器）和控制器之间的分离（服务器端组件处理HTTP请求）定义非常明确。模型-视图-控制器是为了业务逻辑层与用户界面逻辑分离的基本设计模式。不幸的是，这种模式的普及导致了一些的故障描述。特别是术语“控制器”已被用来表示不同的上下文中不同的东西。幸运的是Web应用程序的到来已经帮助解决了一些因为视图与控制器分离如此明显的歧义。JSP框架和ASP.NET都支持MVC模式。然而，如何实现两种模式有着很大的区别。这篇文章中，我们已经讨论过每种技术如何实现MVC模式，和他们的相似之处与差异。在第2节，我们通过使用UML解释模型-视图-控制器。在第3节，我们提供了ASP.Net中的模型-视图-控制器。在第4节，我们提出了Java服务器页面（JSP）中的模型视图控制器框架。在第5节，我们将在ASP.Net中实现MVC与在JSP中实现MVC进行了比较。最后，我们在第6节得出我们的结论。
2.模型-视图-控制器（MVC）架构
MVC设计模式的目标是从表示给用户（视图）的方式和用户控制的方式分离应用程序对象（模型）。Model对象知道所有需要显示的数据。此外，它知道可以应用到转换该对象的所有操作。但是，它不知道任何关于GUI的事情，包括数据被显示的行为，包括操纵数据的GUI行为。数据的访问和操纵是通过独立的GUI进行的。该模型代表企业数据和政府通过和更新数据的商业规则。通常该模型作为软件近似于现实世界的过程，在建模时这么简单的现实世界技术应用。
View对象指的是模型，它使用了模型的查询方法从中获取数据模型，然后显示信息。一个观点是呈现模型的内容，并且它通过模型可以进入企业数据并指定如何展示数据。当模型变化时这是观点的责任以保持其展示的一致性。
通过用户操纵模型中的数据，控制器对象知道其物理意义。控制器与由模型执行的操作的观点进行交互。在一个独立的GUI客户端，用户交互可能是按钮点击或菜单选择，而在Web中应用程序，它们显示为GET和POST HTTP要求。该模型执行的操作包括激活业务流程或改变模型的状态。基于用户交互和模型行为的结果，控制器通过选择适当的视图进行响应。
在GUI中，视图和控制器通常紧密地在一起工作。例如，控制器负责更新模型中一个特定的参数，然后由视图显示。在某些情况下，单个对象既可以用作于控制器又可以作用于一个视图。每个控制器视图对仅与一个模型相关联。但是，一个特定的模型可以有许多视图-控制器对。
2.1模型视图控制器
建模语言可以在视觉上很好地描述模型-视图-控制器，使用由雅各布森在他获奖的《面向对象软件工程》首先引入的鲁棒性分析，并进一步由Doug Rosenberg等在他的书中解释的UML用例驱动对象建模。鲁棒性分析涉及用例的叙事文本，识别一个将参与这些用例的首先猜测的对象集合，并基于他们发挥的角色将这些对象进行分类，并且它可以帮助你在模型-视图-控制器中区分对象范例。鲁棒性分析使持续发现对象成为可能，并帮助你在开始任何额外的设计或开发之前确保你已经确定了大多数主要域类。它们被划分为：
1.描述可以长久存在的实体对象，主要是坚持状态。
2.在系统和环境之间描述链接的边界对象。
3.描述用例特定的对象行为的控制对象。
实体对象不仅仅是信息或边界对象正在寻找的数据。这些可能是数据库表，Excel文件，或者可能是“瞬态”会话或缓存数据。
边界对象是在软件系统中进行通信与之对应的对象（例如，用户）。这些可能是任何窗口，屏幕，对话框和菜单，或系统中的其他用户界面。您可以轻松识别他们，同时分析您的用例。控制对象（控制器）是业务对象或您的商业网络服务。在这里，你可以捕获过滤掉的数据和要呈现给用户的业务规则。所以控制器实际上是控制业务需求或业务本身。这三个UML定型如图2所示。
图2：这三个UML定型的视觉图标
2.2规则
当提取这些对象时，分析你的用例在这些对象中制作交互图，您应该执行以下四个基本规则：
*角色只能跟边界对象对话。
*边界对象只能跟控制员和角色对话。
*实体对象只能跟控制器对话。
*控制器可以与边界对象，实体对象，以及其他对象控制器，但除了角色对话。从图3可以看到唯一的接入点，角色到达任何对象都是通过边界对象。
图3：鲁棒性分析规则
2.3鲁棒性分析和模型-视图-控制器
我们正在使用鲁棒性分析规则来看这些对象如何与模型-视图-控制器相联系。这些对象的映射是：
*实体对象映射到模型对象。
*边界对象映射到视图对象。
*控制器两者都相同。
当我们做鲁棒性分析时，我们可以使用模型-视图-控制器（MVC）对象代替实体边界控制器（EBC）对象。图4显示了这些对象现在的样子。
图4：鲁棒性分析和MVC
模型-视图-控制器是一种隔离不同层次的方法；它可以很容易地维护适中至非常复杂的应用。业务规则频繁更改的情况下，当你为网络开发做一些事情的时候这将是最适合的。图5显示了当Web用户启动查询时MVC的序列图。
图5 MVC的序列图
3.ASP.NET和模型-视图-控制器（MVC）
如果正确地使用，设计模式对解决复杂设计问题非常有用。图6举了一个在ASP.NET中如何实现（MVC）模式的例子。
图6：登录屏幕
该示例反映了与所有三个角色不分开的单页解决方案。这个例子的应用程序是一个登录网页并向用户提供了一个登录屏幕，他可以通过按登录按钮进行访问系统。用户也可以打开复选标记用于记住用户的复选框。此外，当用户登录后，将在服务器端创建一个新的会话，使用Web应用程序的同时保持活动的有效。图7说明了UML角色的用例图（web用户）和登录用例关系。
图7：注册用例
图8显示了使用鲁棒性进入登录的用户的分析图屏幕的场景。用户与登录屏幕进行交互并使用一个启用存储的复选框。
图8：使用鲁棒分析图的场景
图9.序列图
为了更进一步的解释，图9显示了所需的序列图。我们可以安全地分类我们的对象，因为应该有一个主要的控制器，负责该页面的业务逻辑和一个业务服务对象，负责所有的验证，会话管理和cookie设置。也应该有一个DataAccessGateWay（model）对象，可以封装后端数据库对话的所有细节。ASP.Net和Model View的类图控制器如图10所示。以上所有对象最重要的是业务对象也就是控制器对象。
图10: 登录屏幕的类图
3.1 ASP.NET应用程序
ASP.Net应用程序通过使用一个Web应用程序来解释，并具有一个由公司标志，横幅，主要内容和页脚组成的主页。主要内容应以网格视图的形式来显示亲子关系。应该使用两个网格，顶部的一个是主网格而底部的是细节网格。当用户点击在主视图上的任何项目时，详细信息/子视图也会相应地进行更改，并应显示相关的子数据如图11所示。
图11：主视图的视图/操作
图12：母版页设计
母版页设计如图12所示。所以，我们看到的是我们得到的。我们的应用将是由一个主页面，一个HTML框架容器，HTML表组成。 HTML表会包含进一步的两个控件，主用户控制和细节用户控制。这些用户控件依次包含主数据表和细节数据表的视图。数字13显示了对象的必要静态清单，是完成这项工作所必须的。
图13：对象的静态清单
3.1.1 ASP.NET应用程序的鲁棒性分析
我们现在需要一些对象的理解来完成这项工作，但在进入详细设计之前，我们需要通过使用UML来分析应用程序，找出正确的交互和他们之间的关系。这将会完成使用鲁棒性分析，同时在我们心中保持MVC的概念。对于这种情况的概念鲁棒性图如图14所示。
图14：主细节表关系的鲁棒性分析图
此外，图14显示了用户是如何呈现主细节视图的。上层主网格视图是用于选择主表项。所以，每当用户选择主控项目，相应地更新子视图。用户从主网格视图中选择一个项目主用户控制将被通知，而这通知这件事情给倾听者，即是主要控制层对象。主要控制对象会向其他听众通知有关此事件细节用户控制。这些用户控件有直接的访问模型的许可（DataAccessGateway）并使用MsSqlDataLinkAdapter建立MS-SQL数据库连接。图15显示了此情景下的对象交互图。
图15：此场景的对象交互图
主要控制器和细节控制器是不同的控制器。这意味着他们对一次控制一个用户控件和主要控制器对象担任一个整合者的时候微调它们负有责任。当监听器对象需要实现IListner接口时，对于一个作为通知对象的对象，需要实现INotifier接口。不仅如此，监听器对象需要把自己和相关通知者按顺序连接在一起。在这种情况下，我们拥有主要控制器和细节-控制器作为监听器。主要控制器即是监听器又是通知器，并且作为胶水连接他们。但是，在这一点上，我们有所有的关于对象的信息，与工作相关，以及和他们的行为和功能有关。图16显示了主页的完整类设计。
图16：主页的完整类设计
4.JAVA服务器页面（JSP）和模型视图控制器（MVC）
Java Server Pages（JSP）技术在用于构建应用程序的技术动态Web内容，成为杰出Java技术的道路上上是众所周知的。使用JSP的最大优点是它有助于分开演示内容。
4.1 JAVA服务器页面（JSP）模型架构
早期的JSP规范主张了两种使用JSP构建应用程序的模型方法。这些方法被称为JSP模型1和模型2架构。图17和图18说明了这两种架构。
4.1.1 JSP模型1
在模型l的架构中，如图17所示（在附录A中给出），单独的JSP页面负责处理来电请求，调用业务逻辑（在JavaBeans中实现，并不直接在JSP中）更来获取多的细节，并回复客户端。还有分离内容介绍；因为所有的数据访问都是使用bean执行。虽然模型1是适合简单应用，这种架构通常会导
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[137448]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
