MVC框架中英文对照外文翻译文献Word文档下载推荐.docx
《MVC框架中英文对照外文翻译文献Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《MVC框架中英文对照外文翻译文献Word文档下载推荐.docx（32页珍藏版）》请在冰点文库上搜索。
SOA也普遍为消费者的服务提供了一种方式，如基于WEB的应用，以了解可用的基于SOA的服务。
例如，一个公司的几个不同部门可能开发和部署了SOA服务在不同的实现语言；
他们各自的客户通过访问公开，良好定义的接口能从中获益。
XML经常用于SOA服务接口，即使它不是必要的。
JSON也开始变得很常见。
•MVC架构（MVCArchitecture）
MVC是来自Hyfinity的一种新生代的开发应用和集成工具。
基于原生XML,MVC能够使企业规模、基于浏览器的应用快速的开发。
为了快速组装完整的交互式应用程序，MVC提供了直观的图形化IDE（集成开发环境）。
其中一个使MVC区别于大多数传统方法的关键是信息流的概念，它保留了所采集的基于文档的信息，通过数据绑定和路由校验。
这些全部使用原生XML执行。
MVC使用XStudio来开发XML应用，使用XPlatform来运行产生的应用。
MVC主要关注交互式自助应用的发展和使用包括以FromMaker闻名的XStudiio在内的工具来建立完整的WEB应用。
II.MVC架构
正如我们在之前章节所讨论的，普遍认为一个应用应有三个主要层
次：
表现层（UI）,应用逻辑，和资源管理。
在MVC中，表现层划分为了控制器和视图。
最重要的分隔在于表现层和应用逻辑之间。
视图/控制器的分隔相对较少。
MVC包含的不仅仅是架构的应用还有典型的设计模式。
因此结构模式之类的术语可能被用到，再或者是集合设计模式。
•模型（Model）
以特定领域来表现应用操作的信息。
模型是应用逻辑层（有时也叫做域层））的另一种称呼。
应用（或域）逻辑丰富了原始数据的意义（例如，计算今天是否是用户生日，或者购物车中商品的总额，税和运费）。
许多应用利用现有的存储机制（如数据库）来存储数据。
MVC并没有特意提及资源管理层次，因为它被理解为底层的或者封装的模型。
•视图（View）
使模型渲染到表单适合于交互，典型的是一个用户的界面元素。
在WEB应用中经常看到的MVC中，视图是HTML页面和为页面采集动态数据的代码。
•控制器（Controller）
处理和相应事件，尤其是用户actions,并且可能调用模型和视图的变化。
虽然MVC有不同的特性，控制流程一般如下：
1. 用户以某种方式与用户界面进行交互（例如，用户按下一个按钮）。
2. 一个控制器处理来自用户界面的输入事件，经常通过注册操作或回调。
3.控制器访问模型，可能采用适当用户的action方法来更新它
（例如，控制器更新用户的购物车）。
复杂的控制器通常被设计使用命令模式封装action和简化继承。
4. 一个视图使用模型来生成一个合适的用户界面（例如，视图产生一屏购物车内容的列表）。
视图从模型中得到自己的数据。
模型与视图没有直接关联。
（然而，观察者模式可使模型间接通知相关方的变化，包括潜在的视图。
）
5. 用户界面等待进一步用户交互后开始新的循环。
以上数字概述的模型，视图和控制器之间的关系由基于以下。
A. 实现策略
SpringMVC框架是基于分派请求操作的分发器（DispatcherServlet）设计的。
有着可配置的处理器映射（handlermappings）、视图解析器（viewresolution）、本地化（locale）和主题解析器（themeresolution）同时支持上传文件。
B. SpringMVC的特性
■明确分工。
每个角色 控制器，校验器（validator）,命
令对象（commandobject），表单对象（formobject）,模型对象（modelobject）,分发器，处理器映射，视图解析器等等都有专门的对象来实现。
■将框架类和应用类作为JavaBeans的配置强大且直接明了。
包括通过应用上下文配置中间层引用，例如从WEB控制器到业务对象和校验器。
■适用性，不受干扰性，和灵活性。
根据给定场景，用一些参
数注解（例如：
@RequestParam,©
RequestHeader,©
PathVariable,还有很多）来定义你需要的控制器方法。
■可复用业务代码，无需复制。
使用已有的业务对象作为命令对象或者表单对象而不是通过映射来继承特殊的框架基类。
■可定制的绑定和校验。
将类型不匹配作为应用级别校验错误,能保留值，本地化日期和数字绑定等，而不是使用需要手动解析并转换业务对象的且只是字符串的表单对象。
■可定制的处理器映射和视图解析器。
处理器映射和视图解析器策略的范围从简单的基于URL的配置到复杂的专用解析策略。
Spring比WEBMVC框架更加灵活在授权一个特定技术上看来。
■灵活的模型传输。
模型传输是支持根据名字/值的Map,很容易集成任何视图的技术。
■可定制的本地化和主题解析，支持JSP,无论是否使用Spring标签库，支持JSTL,支持不需要额外过度的Velocity等等。
■一个简单且强大的JSP标签库称为Spring标签库，提供的功能如数据绑定和主题。
定制标签允许最大程度的灵活性就标记代码而言。
■在Spring2.0中引入的一种JSP表单标签库能使在JSP界面中写表单更便捷。
■Beans的生命周期范围是当前HTTP请求或HTTP会话。
它并不
是SpringMVC本身具体特征，而是SpringMVC使用了
WebApplicationContext容器的。
图1.MVC架构
C.可插拔性的其他MVC的实现
如果你不想使用Spring的WEBMVC,但打算使用Spring提供的其它功能,你可以很容易地将你选择的WEBMVC框架和Spring整合。
直接通过Spring的Context-LoaderListener启动一个Spring根应用上下文，通过它的ServletContext属性（或者Spring的各种帮助方法）来访问来自Struts或者WebWork的action。
没有"
plugins”参与，所以也没有针对它整合的必要。
从WEB层的角度看，你只要使用Spring作为库，带有根应用上下文的实例作为切入点。
你所注册的beans和Spring的服务随时可访问及时在没有
Spring的WEBMVC的情况下。
Spring并没有在这种情景下与Struts或者WebWork竞争。
它只是提供了纯WEBMVC框架在很多领域所不具备的，从bean配置到数据访问和事务处理。
所以你可以用Spring中间层和/或数据访问层来丰富你的应用，及时你只是想使用，好比,JDBC和Hibernate这样的抽象事务管理。
Spring的WEBMVC框架同很多其他的WEB框架一样，是由请求驱动的。
围绕着一个能将请求分发到控制器的servlet设计，它还提供其他有利于WEB应用开发的功能。
然而Spring的分法器所做的不仅如此。
它完整的整合了Springloc容器使你能够使用Spring所具有的其他功能。
SpringWebMVC分发器的请求处理工作流在下方的图说明。
模式理解阅读器会识别分发器是“前端控制器”设计模式的表达式（这是一种SpringWEBMVC与其他许多领先框架共享的模式）。
分发器是一个真正的Servlet（它继承至HttpServlet基础类），并同样要在你的web应用的web.xml文件中声明。
你需要映射你想让分发器处理的请求，通过在同个web.xml文件中使用URL映射。
这是标准的J2EEservlet配置。
<
web~app>
servlet>
servlet-name>
example<
/servlet-name>
servlet-class>
org.springframework.web.servlet.DispatcherServlet<
/servlet-class>
<
load-on-startup>
l<
/load-on-startup>
/servlet>
servlet-mapping>
url-pattern〉*,form<
/url-pattern>
/servlet-mapping>
/web~app>
在上面的例子中，所有以.form结尾的请求会被
exampleDispatcherServlet处理。
这只是配置SpringWEBMVC的第一步。
你现在需要使用SpringWebMVC框架配置各种beans□当初始化一个分发器，框架会查找一个名为
[servlet-name]-servlet,xml在你的Web应用的WEB-INF目录下并创建里面所定义的beans,重定义所有全局同名定义的beans□
图2.请求处理工作流
Spring分发器使用特有的beans来处理请求和显示相应的视图。
这些beans就是Spring框架的一部分。
你可以在
WebApplicationContext中配置它们，配置方式就象配置其它bean的方式一样。
然后，对于大多数bean来说，已经提供了合理的缺省配置，所以你最初不需要配置它们。
在你启动好分发器后，且有一个请求触发了指定的分发器，接下
来分发器按以下步骤处理请求：
1. 查找WebApplicationContext,并绑定该请求成为一个属性，使控制器和其他处理器在处理过程中能使用。
缺省绑在分发
器.WEB_APPLICATION_CONTEXT_ATTRIBUTE这个关键字上。
2. 绑定本地化信息解析器到请求上，使处理过程中的处理器在处理请求（显示视图，准备数据等）时能解析本地化信息。
如果你不需要本地化信息解析器，就忽视它。
3. 绑定主题解析器到请求上，让视图之类的元素能决定使用哪个主题。
如果你不需要主题，你可以忽视它。
4. 如果你指定了多文件解析器，请求会被检测是否使用了multiparts；
若是，请求会保存到MultipartHttpServletRequest中，以便处理过程中的其他处理器进一步处理。
5. 查找合适的处理器。
如果找到，为了准备模型数据或渲染视图，与该处理器（预处理器，后处理器，控制器）相关的执行链会被执行。
6. 如果模型返回数据，就显示视图。
否则，（可能由于安全因素,被前处理器或后处理器拦截了请求），无视图显示，因为请求已经被结束。
III.控制器实现
Spring2.5引入了基于注解的编程模型，MVC的控制器可以使用诸如©
RequestMapping,©
RequestParam,©
ModelAttribute等注解。
注解能同时支持ServletMVC和PortletMVC。
这种方式实现的控制器无需继承指定的基类或者实现指定的接口。
而且，它们通常不直接依赖于Servlet或PortletAPIs,但你可以很配置访问到Servlet或Portlet设置。
©
Controller
publicclassHelloWorldController（
@RequestMapping（〃/helloWorld〃）
publieModelAndViewhelloWorldO（
ModelAndViewmav=newModelAndView（）;
mav.setViewName（/，helloWorld，z）;
mav.addObject（"
message”,"
HelloWorld!
z，）;
returnmav;
}
你能够看到，©
Controller和©
RequestMapping注解允许灵活的方法名和签名。
在这上面的例子中的方法没有参数，返回一个ModelAndView,但还有其他各种（更好的）策略的存在，会在本章后面介绍。
ModelAndView,©
Controller,和©
RequestMapping是SpringMVC实现的基础组成。
这章节文档会介绍这些注解如何普遍的在Servlet中应用。
©
Controller表明一个独有的类为一个控制器服务。
Spring不要求你继承任何控制器的基类或引用ServletAPI。
然而，你仍能引用你需要的Servlet其他的功能。
Controller注解以固定注解类形式来表明它的角色。
分发器就可以通过该注解来获取这个类中带有©
RequestMapping注解的方法。
你可以明确的注解控制器bean,通过在分发器上下文中使用标准的Springbean定义。
然而，@Controller模式也允许自动侦测,在类路径中匹配Spring的公共侦测组件类并为他们自动注册bean定义。
要实现注解控制器自动探测，需要在配置文件中加入探测组件。
A,用©
RequestMapping映射请求
使用©
RequestMapping注解来映射就像/appointments这样的URLs到整个类或特定的处理方法。
一般来说，类级别的注解映射特定的请求路径到表单控制器上，而方法级别的注解只是映射为一个特定的HTTP方法请求（“GET”，“POST”等）或HTTP请求参数。
下这个例子显示了在SpringMVC应用中的一个控制器使用该注解：
RequestMapping（〃/appointments^）
publicclassAppointmentsController（
privatefinalAppointmentBookappointmentBook;
Autowired
publicAppointmentsController（AppointmentBookappointmentBook）（this.appointmentBook=appointmentBook;
RequestMapping（method二RequestMethod.GET）
PublicMap<
String,Appointment>
get（）{
returnappointmentBook.getAppointmentsForToday（）;
@RequestMapping（value二〃/{day}〃，method二RequestMethod.GET）
publicMap<
getForDay（©
PathVariable
DateTimeFormat（iso=IS0.DATE）Dateday,Modelmodel）（returnappointmentBook.getAppointmentsForDay（day）;
回RequestMapping（value—/new”,method=RequestMethod.GET）
publicAppointmentFormgetNewFormO（
returnnewAppointmentForm（）;
RequestMapping（method=RequestMethod.POST）
publicStringadd（©
ValidAppointmentFormappointment,BindingResultresult）（if（result.hasErrors（））（
return〃appointments/new〃；
appointmentBook.addAppointment（appointment）;
return"
redirect:
/appointments^;
在例子中,©
RequestMapping在多处使用到。
第一种用法在类级别上,表明该控制器中的所有处理方法与/appointments路径有关。
get（）方法进行进一步©
RequestMapping细化配置:
它只接受GET请求，也就意味着只有/appointments路径下的HTTPGET请求才调用该方法。
post（）方法有类似的细节，通过getNewFormO方法与HTTP方法和路径的定义合而为,/appointments
/new的GET请求能够处理该方法。
B.支持的处理方法参数和返回类型
RequestMapping注解的处理方法拥有十分灵活的签名。
大多数可以不按顺序的使用。
•请求或响应对象（ServletAPI）,选择任意指定的请求或响应类型，例如ServletRequest或HttpServletRequesto
• 会话对象（ServletAPI）:
HttpSession类型的。
这种类型的参数强转成一个相应存在的sessiono所以，这样的参数绝不会为空。
• ©
PathVariable注解方法参数并将其绑定到URI模板变量的值上。
RequestParam对访问指定Servlet请求的参数注解。
参数值转化成方法中声明的类型。
• @RequestHeader对访问指定的Servlet的HTTP请求头参数注解。
参数值转化成方法中声明的类型。
• ModelMap丰富了隐式模型，对于WEB视图是可见的。
• BindingResult返回先前指令或表单对象的校验结果。
•标记处理完成的表单状态，会触发清理在处理器类型级别已被©
SessionAttributes注解表明的会话属性。
接下来是处理器方法所支持的返回类型：
• 一个ModelAndView对象，这个模式隐含指令对象和参考数据存取方法@ModelAttribute注解的结果。
•—个模型对象，视图名则通过RequestToViewNameTranslator把请求转换为视图名称。
• 一个Map对象来表示模型，而视图名则利用
RequestToViewNameTranslator把请求转换为视图名称。
• 一个视图对象，该处理方法还可以以编程方式通过声明一个模型参数丰富模型（见上）。
• 一个String对象来表示视图名，处理器中对于的方法也可以通过声明一个ModelMap的参数来表示model□
•空（void）表示方法自己处理响应（通过声明一个
ServletResponse或HttpServlet-
Response直接输出响应内容）或者通过
RequestToViewNameTranslator把请求转化为视图名（此方法不用在处理方法中声明一个response参数）。
•其他任何的返回类型被当做一个单一的模型属性展示给视图，通过在方法级别指定©
ModelAttribute来使用属性名（或基于返回类名的缺省属性名）。
IV.视图
所有WEB应用的MVC框架都提供了访问视图的方法。
Spring提供了视图解析器，使你提交模型到浏览器而无需绑定特定的视图技术。
不同一般的，Spring允许你使用JSPs,Velocity模板和XSLT等多种视图。
Spring处理视图最重要的两个接口是ViewResolver和View。
ViewResolver接口在视图名称和真正的视图之间提供映射；
而View接口访问请求准备并提交请求给其中一种视图技术。
A. 用视图解析器接口解析视图
在SpringWEBMVC处理器中所有处理器方法必须解析一个逻辑视图名，无论是显示的还是隐式的。
Spring中的视图通过被视图解析器解析后的逻辑视图名来访问。
Spring有很多视图解析器。
ResourceBundleViewResolver检查ResourceBundle定义下的bean名称，并解析每个视图。
它用属性值［视图名］.（class）作为视图类，属性值［视图名］.url作为视图url0
B. 视图重定向
正如先前提到的，一个控制器一般返回一个逻辑名，解析器再将其解析成特定的视图技术。
对于如JSPs这样通过Servlet或JSP引擎来处理视图的技术来说，它的解决方案通常要结合InternalResourceViewResolver和InternalReSourceView,通过RequestDispatcher.forward（）方法或者
RequestDispatcher.include（）方法发布内部转发或包含指令。
对于其他诸如Velocity,XSLT的视图技术，视图本上直接输出内容到响应流。
有时在视图渲染前发布HTTP重定向指令返回客户端是会发生的，当一个控制器已经被POSTed的数据调用，并且响应已经委托给另一个控制器（例如成功提交表单）。
在这种情况下，一个常规的内部转发将意味着其他控制器也可能会看到相同的POST数据，如果它与其他预期的数据混淆是个潜在的问题。
消除用户多次提交表单的可能性是另一个显示结果前执行重定向的原因。
在这种情况下，浏览器会先发送原始的POST；
得到响应后重定向到不同的URL；
最后浏览器会显示GET后来在重定向响应指定的URL。
这样一来，从浏览器看来，当前页没有反射POST的结果而是GET的。
最后影响用户没有办法通过刷新，偶然地重POST同样的数据。
刷新出的是GET的结果
升级会员 