英语原文共 6 页，剩余内容已隐藏，支付完成后下载完整资料
SpringMVC Framework forWeb 2.0
摘要：当构建丰富的用户体验Web应用程序时，可以使用丰富的Web应用程序框架，并且只有很少的指导才能做出决策。 Web 2.0应用程序允许个人在线管理他们的内容，并与Web上的其他用户和服务共享。这种共享需要访问控制。然而，现有的访问控制解决方案不能令人满意，因为它们不提供用户在开放和用户驱动的Web环境中所需的功能。在所有这些Web开发框架中，最受欢迎的是MVC框架。模型视图控制器（MVC）是一种软件架构，目前被认为是软件工程中使用的架构模式。该模式从用户界面（输入和显示）中分离出“域逻辑”（用户的应用程序逻辑），允许对每个（分离关注）进行独立开发，测试和维护。模型视图控制器（MVC）模式创建应用程序，分离应用程序的不同方面（输入逻辑，业务逻辑和UI逻辑），同时提供这些元素之间的松散耦合。
- 引言
那么什么将网站定义为“Web 2.0”呢？ 对此有很多不同的意见，难以确定确切的定义。 但是，当我们将通过所有可用的Web开发框架时，它将会变得清楚。用于Web开发的各种架构如下
1、
在软件工程中，多层架构（通常称为n层架构）是一种客户机 - 服务器架构，其中演示，应用处理和数据管理在逻辑上是独立的过程。[6] 例如，使用中间件来为用户和数据库之间的数据请求提供服务的应用程序采用多层架构。 多层架构的最广泛使用是三层架构。 N层应用程序架构为开发人员提供了一个创建灵活且可重用的应用程序的模型。 通过将应用程序分解成层，开发人员只需要修改或添加特定的层，而不必重写整个应用程序。 应该有一个表示层，业务或数据访问层，以及一个数据层。 层和层的概念通常可互换使用。
2、面向服务的架构
在软件工程中，面向服务架构（SOA）是以互操作性服务的形式设计和开发软件的一套原则和方法。 这些服务是明确的业务功能，它们被构建为可以重复用于不同目的的软件组件（代码和/或数据结构的离散件）。 在系统开发和集成的阶段，使用SOA设计原则。 SOA还通常为诸如基于Web的应用程序等服务的消费者提供一种方式来了解可用的基于SOA的服务。 例如，公司内部的不同部门可以用不同的实现语言来开发和部署SOA服务; 他们各自的客户将受益于一个理解明确的接口来访问它们。 XML通常用于与SOA服务的连接，尽管这不是必需的。 JSON也越来越普遍。
- MVC架构
MVC是Hyfinity新一代应用开发和集成工具的一部分。 基于本机XML，MVC可以快速开发基于企业级浏览器的应用程序。 MVC提供了直观的图形化IDE，用于快速组合完整的交互式应用程序。 MVC和更传统的方法之间的主要区别之一是信息流概念，它将基于文档的信息从捕获，验证到数据绑定和路由保留。 所有这一切都是使用原生XML执行的。
MVC使用XStudio开发XML应用程序和XPlatform来托管生成的应用程序。 MVC主要关注交互式自助服务应用程序的开发，并在XStudio中使用一种称为FormMaker的工具来构建完整的Web应用程序。
- MVC架构
正如我们在上一节所讨论的，通常认为一个应用程序有三个主要层：演示（UI），应用逻辑和资源管理。 在MVC中，表示层被分为控制器和视图。 最重要的分离是介绍和应用程序逻辑。 视图/控制器拆分较少。 MVC涵盖了比设计模式典型的更多的应用架构。 因此，术语建筑模式可能是有用的，或者可能是聚集设计模式。
- 模型
应用程序运行的信息的域特定表示。 该模型是应用程序逻辑层（有时也称为域层）的另一个名称。 应用程序（或域）逻辑会为原始数据添加意义（例如，计算今天是用户的生日，还是购物车项目的总计，税费和运费）。 许多应用程序使用持久存储机制（如数据库）来存储数据。 MVC没有具体提及资源管理层，因为它被理解为由Model下面或封装。
- 视图
将模型渲染为适合交互的形式，通常是用户界面元素。 MVC经常在Web应用程序中看到，其中的视图是HTML页面和为页面收集动态数据的代码。
- 控制器
处理和响应事件，通常是用户操作，并可以调用模型和视图上的更改。
虽然MVC有不同的风格，但控制流程通常如下：
1.用户以某种方式与用户界面进行交互（例如，用户按下按钮）。
2.控制器通常通过注册的处理程序或回调来处理来自用户界面的输入事件。
3.控制器访问模型，可能以适合用户操作的方式更新（例如，控制器更新用户的购物车）。 复杂控制器通常使用命令模式进行结构化，以封装动作并简化扩展。
4.视图使用模型来生成适当的用户界面（例如，视图产生列出购物车内容的屏幕）。 该视图从模型中获取自己的数据。 该模型没有直接了解的观点。 （然而，观察者模式可以用于允许模型间接通知感兴趣的各方，包括观点，变化）。
5.用户界面等待进一步的用户交互，从而重新开始循环。
上图概括了模型，视图和控制器之间的关系如下。
- 实施战略
Spring Web模型视图控制器（MVC）框架围绕一个DispatcherServlet设计，它将请求分派给处理程序，具有可配置的处理程序映射，视图分辨率，区域设置和主题解析以及支持上传文件。
B.Spring Web MVC的特点
- 明确分离角色。 每个角色 - 控制器，验证器，命令对象，表单对象，模型对象，DispatcherServlet，处理程序映射，视图解析器等都可以由专门的对象来实现。
- 框架和应用程序类作为JavaBeans的强大而直接的配置。此配置功能包括跨上下文的简单引用，例如从Web控制器到业务对象和验证器。适应性，非侵入性和灵活性。 定义您需要的任何控制器方法签名，可能使用给定方案的参数注释之一（例如@RequestParam，@RequestHeader，@PathVariable等）。
- 可重用的业务代码，不需要重复。 使用现有的业务对象作为命令或表单对象，而不是镜像它们来扩展特定的框架基类。
- 可定制的绑定和验证。 键入不匹配作为应用程序级验证错误，保持违规值，本地化日期和数字绑定等，而不是只使用仅包含字符串的表单对象进行手动解析和转换为业务对象。
- 可定制的处理程序映射和视图分辨率。 处理程序映射和视图分辨率策略的范围从简单的基于URL的配置到复杂的专用分辨率策略。 Spring比Web MVC框架更灵活，这些框架需要特定的技术。
- 灵活的模型转移。 具有名称/值的模型传输Map支持与任何视图技术的轻松集成。
- 可定制的区域设置和主题解析，支持带有或不带有Spring标签库的JSP，支持JSTL，支持Velocity，无需额外的桥接等。
- 一个简单而强大的JSP标签库，被称为Spring标签库，可以为数据绑定和主题等功能提供支持。 自定义标签允许在标记代码方面具有最大的灵活性。
- 在Spring 2.0中引入的JSP表单标签库，使得在JSP页面中的写入表单更容易。
- Bean的生命周期范围限定在当前的HTTP请求或HTTP Session中。 这不是Spring MVC本身的一个特定功能，而是Spring MVC使用的WebApplicationContext容器。
C.其他MVC实现的可扩展性
如果您不想使用Spring的Web MVC，但是打算利用Spring提供的其他解决方案，您可以轻松地将您选择的Web MVC框架与Spring集成。 通过其ContextLoaderListener简单地启动Spring根应用程序上下文，并通过其Struts或WebWork操作中的ServletContext属性（或Spring各自的帮助方法）访问它。 没有涉及“插件”，因此不需要专门的集成。 从Web层的角度来看，您只需使用Spring作为库，将根应用程序上下文实例作为入口点。
即使没有Spring的Web MVC，您的注册bean和Spring的服务也可以在您的指尖。 在这种情况下，Spring不会与Struts或WebWork竞争。 它简单地解决了纯Web MVC框架从bean配置到数据访问和事务处理的许多方面。 所以您可以使用Spring中间层和/或数据访问层来丰富您的应用程序，即使您只想使用JDBC或Hibernate的事务抽象。
Spring的Web MVC框架与许多其他Web MVC框架一样，以请求为驱动，围绕中央servlet设计，将请求分派给控制器，并提供其他功能，有助于Web应用程序的开发。 但是，Spring的DispatcherServlet不仅仅是这样做。 它与Spring IoC容器完全集成，因此允许您使用Spring的其他所有功能。
Spring Web MVC DispatcherServlet的请求处理工作流程如下图所示。 模式精明的读者将会认识到，DispatcherServlet是“前端控制器”设计模式的表达（这是Spring Web MVC与许多其他领先的Web框架共享的模式）。
DispatcherServlet是一个实际的Servlet（它继承自HttpServlet基类），[3]，因此在Web应用程序的web.xml中声明。 您需要通过使用同一web.xml文件中的URL映射来映射要DispatcherServlet处理的请求。 这是标准的J2EE servlet配置; 以下示例显示了这样的DispatcherServlet声明和映射。
在前面的示例中，以.form结尾的所有请求都将由exampleDispatcherServlet处理。 这只是设置Spring Web MVC的第一步。 您现在需要配置Spring Web MVC框架使用的各种bean。 在DispatcherServlet初始化时，框架将在Web应用程序的WEB-INF目录中查找名为[servlet-name] -servlet.xml的文件，并创建在那里定义的bean，覆盖使用相同名称定义的任何bean的定义在全球范围内。
Spring DispatcherServlet使用特殊的bean来处理请求并呈现适当的视图。 这些bean是Spring框架的一部分。 您可以在WebApplicationContext中配置它们，就像配置任何其他bean一样。 但是，对于大多数bean，提供了明智的默认值，因此您最初不需要配置它们。 这些bean在下表中描述。
在您设置了DispatcherServlet并且针对该特定DispatcherServlet启动了一个请求后，DispatcherServlet将按如下所示开始处理请求：
1. WebApplicationContext在请求中搜索并绑定，作为控制器和进程中的其他元素可以使用的属性。 默认情况下，它将在DispatcherServlet.WEB_APPLICATION_CONTE XT_ATTRIBUTE键下绑定。
2.语言环境解析器绑定到该请求，以使进程中的元素能够解决在处理请求时使用的语言环境（渲染视图，准备数据等）。 如果您不需要语言环境解析，则不需要它。
3.主题解析器必须符合要求，让诸如视图等元素决定要使用哪个主题。 如果不使用主题，可以忽略它。
4.如果指定了多部分文件解析器，则会对多部分进行检查。 如果找到多部分，则请求被包装在一个MultipartHttpServletRequest中，以便进程中的其他元素进一步处理。
5.搜索适当的处理程序。 如果找到处理程序，则执行与处理程序（预处理程序，后处理程序和控制器）关联的执行链，以便准备模型或呈现。
6.如果返回模型，则呈现视图。 如果没有返回模型（可能是由于预处理程序或后处理程序拦截请求，可能是出于安全原因），因为请求可能已经被满足，所以不会呈现任何视图。
三、实施控制器
Spring 2.5引入了一种基于注释的编程模型，用于使用诸如@RequestMapping，@RequestParam，@ModelAttribute等注释的MVC控制器。此注解支持可用于Servlet MVC和Portlet MVC。以这种风格实现的控制器不必扩展特定的基类或实现特定的接口。此外，它们通常不直接依赖于Servlet或Portlet API，尽管您可以轻松配置对Servlet或Portlet设施的访问。您可以看到，@Controller和@RequestMapping注释允许灵活的方法名称和签名。在这个特定的例子中，该方法没有参数并返回一个ModelAndView，但是存在各种其他（和更好的）策略，如本节稍后所述。 ModelAndView，@Controller和@RequestMapping构成了Spring MVC实现的基础。本节介绍这些注释以及它们在Servlet环境中最常用的注释。
@Controller注释表示特定的类用于控制器的角色。 Spring不需要扩展任何控制器基类或引用Servlet API。 但是，如果需要，您仍然可以参考Servlet特定的功能。 @Controller注释作为注释类的构造型，表示其作用。 调度程序扫描这些注释类以获取映射方法，并检测@RequestMapping注释。 您可以使用调度程序上下文中的标准Spring bean定义来明确定义带注释的控制器bean。 但是，@Controller构造型还允许自动检测，与Spring通用支持一致，用于检测类路径中的组件类，并为它们自动注册bean定义。 要启用
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[139421]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
课题毕业论文、外文翻译、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
