-
中英文对照外文翻译文献
(
文档含英文原文和中文翻译
)
译文：
Web 2.0
下的
Spring
MVC
框架
摘要
-
当要建立丰富用户体验的<
/p>
WEB
应用时，有大量的
WED
应用框架
可以使用，却很少有该选择哪一种的指导。
WEB 2.0
应用允许个体管理
他们自己的在线网页，并
能与其他在线用户和服务器共享。这样分享需
要访问控制器来实现。然而，现有的访问控
制器解决方案不是令人很满
意。因为在开放且由用户主导的
WE
B
环境下，它满足不了用户的功能需
求。
MVC
框架是在所有的
WEB
开发框
架中最受欢迎的。模型
-
视图
-
控制
器（
MVC
）是
一种软件架构，如今被认为是一种体系结构在软件工程模
式中使用。
该模式从用户界面
（输入和演示）
分离出了
“领域逻辑”
（基
于用户的应用逻辑）
，
它允许独立地开发，
测试和维护每个分离的部分。<
/p>
模型
-
视图
-<
/p>
控制器（
MVC
）模型创建的应用分离为
不同的层次应用，同
时在每两者之间建立松散的耦合。
关键字
- Spring
MVC,
结构，
XStudio, SOA,
控制器
I.
绪论
如何确切地定义一个网站为“
WEB 2.0
< br>”的呢？关于这有着许多不同
见解，使它很难精确地下一个确切的定论。但当我们
将所有的
WEB
开发
框架过一遍之后它
就会变得清晰了。各种基于
WEB
开发的架构如下：
?
Ntier
架构（
Ntier
Architecture
）
在软件
工程中，
多层架构
（常被称为
n-ti
er
架构
）是一种表示层，
应用处理层
和数据管理层在逻辑上分开处理的客户端
-
服务器架构。例
如，
一个应用在用户与数据库之间使用中间件提供数据请求服务就用
到
了多层体系结构。最为广泛应用的多层体系结构是
三层架构<
/p>
。
N-tier
应用架构为开发者提供了
用来创建了一个灵活且可复用的模型。
通过打
破应用层次，开发
者只需修改或添加一个特定的层，而不是要去重写一
遍整个应用。它需要有一个表示层，
一个业务层或者数据访问层和一个
数据层。层（
layer
）和层
(tier)
之间的概念常常是可以
互换的。
?
服务导向架构（
Service Oriented
Architecture
）
在软件
工程中，服务导向架构（
SOA
）是一套原则，是一种软件设计
开发的方法，基于以可互操作服务形式。这些服务是明确的业务功能，
< br>由可重用于不同方面的软件组件（离散代码块和
/
或数据
结构）组成。
SOA
设计原则被应用到了系统开发和集成的各个
阶段。
SOA
也普遍为消
费者的服务提
供了一种方式，
如基于
WEB
的应用，
以了解可用的基于
SOA
的服务。
例如，一个公司的几个不同部门可能开发和部署了
SOA
服务在
不同的实现语言；他们各自的客户通过访问公开，良好定义的接口能
从
中获益。
XML
经常用于
SOA
服务接口，即使它不是必要的。
JSON<
/p>
也开始
变得很常见。
?
MVC
架构（
MVC
Architecture
）
MVC
是来自
Hyfinity
的一种新生代
的开发应用和集成工具。基于原
生
XML
，
MVC
能够使企业规模、基于浏览器的应用快速的开发。为
了快
速组装完整的交互式应用程序，
MVC
提供了直观的图形化
IDE
（集成开
发环境）。其中一个使
MVC
区别于大多数传统方法的关键是
信息流的概
念，它保留了所采集的基于文档的信息，通过数据绑定和路由校验。这
些全部使用原生
XML
执行。
MVC
使用
XStudio
来开发
XML
应用，
< br>使用
XPlatform
来运行产生的应
用。
MVC
主要关注交互式自助应用的发展和使用包括
以
FromMaker
闻名
的
XStudiio
在内的工具来建立完整的
WE
B
应用。
II.
MVC
架构
正如我们在之前章节所讨
论的，普遍认为一个应用应有三个主要层
次：表现层（
UI
），应用逻辑，和资源管理。在
MVC
中，
表现层划分为
了控制器和视图。最重要的分隔在于表现层和应用逻辑之间。视图
/
控
制器的分隔相对较少。
MVC
包含的不仅仅是架构的应用还有典型的设计
模式。因
此结构模式之类的术语可能被用到，再或者是集合设计模式。
?
模型（
M
odel
）
以特定领域来表现应用操
作的信息。模型是应用逻辑层（有时也叫
做域层）
）
的另一种称呼。
应用
（或域）
逻辑丰富了原始数据的意义
（例
如，
计算今天是否是用户生日，
或者购物车中商品的总额，
税和运
费）
。
许多应用利用现有的存储机制（如数据库）来存储数据。
MVC
并没有特
意提及资源管理层次，
因为它被理解为底层的或者封装的模型。
?
视图（
V
iew
）
使模型渲染到表单适合于交
互，典型的是一个用户的界面元素。在
WEB
应用中经常看到的
MVC
中，
视图是
HTML
页面和为页面采集动态数据
的代码。
?
控制器（
Controller
）
处理和相应事件，
尤其是用户
actions
，
并且可能调用模型和视图的
变化。
< br>
虽然
MVC
有不同的特性，控
制流程一般如下：
1.
用户以某种方
式与用户界面进行交互（例如，用户按下一个按
钮）。
2.
一个控制器处理来自用户界面的输入事件，
经常通过注册操作
或回调。
3.<
/p>
控制器访问模型，可能采用适当用户的
action
方法来更新它
（例如，控制器更新用户的购物车）。复杂的控制器通常被设计
使
用命令模式封装
action
和简化
继承。
4.
一个视图使用模型来生成
一个合适的用户界面（例如，视图产
生一屏购物车内容的列表）。视图从模型中得到自己
的数据。模型
与视图没有直接关联。（然而，观察者模式可使模型间接通知相关
方的变化，包括潜在的视图。）
5.
用户界面等待进一步用户交互后开始新的循环。
以上数字概述的模型，视图和控制器之间的关系由基于以下。
A.
实现策略
SpringMVC
框架是基于分派请求操作的分发器
（
DispatcherServlet
）
设
计的。有着可配置的处理器映射（
handler
mappi
ngs
）、视图解析器
（
view r
esolution
）、本地化（
locale
）和主题解析器（
theme
resolution
）同时支持上传文件。
MVC
的特性
?
明确分工。每个角色——控制器，
校验器（
validator
），命
令
对象（
command object
）
,
表单对象（
form
object
）
,
模
型对象（
model
object
）
,
< br>分发器
,
处理器映射
,
视图解析器
等等都有专门的对象来实现。
?
将框架类和应用类作为
JavaBeans
的配置强大且直接明了。
包括
通过应用上下文配置中间层引用，例如从
WEB
控制器到
业务对象和校验器。
?
适用性，不受干扰性，和灵活性。
根据给定场景，用一些参
数注解（例如：
@RequestPa
ram,@RequestHeader,@PathVariable
，
还有很多）
来定义你需要的控制器方法。
?
可复用业务代码，无需复制。使用
已有的业务对象作为命令
对象或者表单对象而不是通过映射来继承特殊的框架基类。
?
可定制的绑
定和校验。
将类型不匹配作为应用级别校验错误，
能保留值，本
地化日期和数字绑定等，而不是使用需要手动
解析并转换业务对象的且只是字符串的表单
对象。
?
可定制的处理器映射和视图解析器。处理器映射和视图解析
器策略的范围从简单的基于<
/p>
URL
的配置到复杂的专用解析策
略。<
/p>
Spring
比
WEB MVC
框架更加灵活在授权一个特定技术上
看来。
?
灵活的模型传输。模型传输是支持
根据名字
/
值的
Map
，很容
易集成任何视图的技术。
?
可定制的本地化和主题解析，
支持
JSP
，
无论
是否使用
Spring
标签库，支持
J
STL
，支持不需要额外过度的
Velocity
等等。
?
一个简单且强大的
JSP
标签库称为
Spring
标签库，
提供的功
能如数据绑定和主题。定制标签允许最大程度的灵活性就标
记代码而言。
?
在
< br>Spring2.0
中引入的一种
JSP
表单标签库能使在
JSP
界面
中写表单更便捷。
?
Beans
的生命周期范围是当前
HTTP
请求或
HTTP
会话。
它并不
是
Spring
MVC
本身具体特征，而是
Spring MVC
使用了
WebApplicationContext
容器的。
图
架构
C.
可插拔性的其他
MVC
的实现
如果你不想使
用
Spring
的
WEB MVC
，但打算使用
Spring
提供的
其它功能，
你可以很容易地将你选择的
WEB
MVC
框架和
Spring
整合。
直接通过
Spring
的
Context-LoaderListener
启动一
个
Spring
根应
用上下文，通过它
的
ServletContext
属性（或者
< br>Spring
的各种帮
助方法）
来访问来自
Struts
或者
WebW
ork
的
action
。
没有
参与
,
所以也没有针对它整合的必要。从
WEB
层的角度看
，你只要
使用
Spring
作为库，带
有根应用上下文的实例作为切入点。
你所注册的
beans
和
Spring
的服务随时可访问及时在没有
Spring
的
< br>WEB
MVC
的情况下。
Sp
ring
并没有在这种情景下与
Struts
< br>或者
WebWork
竞争。它只是提供了纯
WEB MVC
框架在很多领域所不
具备的，
从
bean
配置到数据访问和事务处理。
所以你可以用
Spring
中间层和
/
或数据访问层来丰富你的应用，
及时你只是
想使用，
好比，
JDBC
和
Hibernate
这样的抽象事务管理。
Spring
的
WEB
MVC
框架同很多其他的
WEB
框架一样，
是由请求驱
动的。围绕着一个能将请求分发到控
制器的
servlet
设计，它还提
供
其他有利于
WEB
应用开发的功能。
然
而
Spring
的分法器所做的不
仅如
此。它完整的整合了
Spring Ioc
容器使你能够使用<
/p>
Spring
所
具有的其他功能。
Spring
Web
< br>MVC
分发器的请求处理工作流在下方的图说明。模式
理
解阅读器会识别分发器是“前端控制器”设计模式的表达式（这
是一种
< br>Spring WEB MVC
与其他许多领先框架共享的模式）。
< br>分发器是一个真正的
Servlet
（它继承至
HttpServlet
基础类）
，
并同样要在你的
web
应用的
文件中声明。你需要映射你想
让分发器处理的请求
,
通过在同个
文件中使
用
URL
映射。
这
是标准的
J2EEservlet
配置。
< br>
...
在上面的例子中，所有以
.form
结尾的请求会被
exampleDisp
atcherServlet
处理。这只是配置
Spring
WEB
MVC
的第
< br>一步。你现在需要使用
Spring Web MVC
框
架配置各种
beans
。当初
始化一个
分发器，框架会查找一个名为
[servlet-name]-
在你的
Web
应用的
WEB-INF<
/p>
目录下并
创建里面所定义的
beans<
/p>
，重定义所有全局同名定义的
beans
。
图
2.
请求处理工作流
Spring
分发器使用特有的
beans
来处理请求和显
示相应的视图。
这些
beans
就是<
/p>
Spring
框架的一部分。你可以在
W
ebApplicationContext
中配置它们，配置方式就象配置其它
bean
的方式一样。然后，对于大多数
be
an
来说，已经提供了合理的缺省
配置，所以你最初不需要配置
它们。
在你启动好分发器后，且有一个请求触发了指定的分发
器，接下
来分发器按以下步骤处理请求：
1.
查找
WebApplicationContext<
/p>
，并绑定该请求成为一个属性，
使控制器和其他处理器在处理过程
中能使用。缺省绑在分发
器
.WEB_APPLICATION
_CONTEXT_ATTRIBUTE
这个关键字上。
2.
绑定本地化信息解析器到请求上，
使处
理过程中的处理器在处
理请求（显示视图，准备数据等）时能解析本地化信息。如果你不
需要本地化信息解析器，就忽视它。
3.
绑定主题解析器到请求上，
让视图之类的元素能决定使用哪
个
主题。如果你不需要主题，你可以忽视它。
4.
如果你指定了多文件解析器，请求会被检测是否使用了
multiparts
；若是，请求会保存到
Multip
artHttpServletRequest
中，以便处理过程中的其他处理器进一步
处理。
5.
查找合适的处理器。
如果找到，
为了准备模型数据或渲染视图，
与该处理器（预处理器，后处理器，控制器）相关的执行链会被执
行。
< br>
6.
如果模型返回数据，
就显
示视图。
否则，
（可能由于安全因素，
被前处理器或后处理器拦截了请求），无视图显示，因为请求已经
被结束。
III.
控制器实现
Spring 2.5
引入了基于注解的编程模型，
MVC
的控制器可以使用诸
如
@RequestMapping, @RequestParam, @ModelAttribute< /p>
等注解。注解
能同时支持
Servlet
MVC
和
Portlet MVC
。这
种方式实现的控制器无需
继承指定的基类或者实现指定的接口。而且，它们通常不直接依
赖于
Servlet
或
Portlet
APIs
，但你可以很配置访问到
Servlet
或
Portlet
设置。
@Controller
public class
HelloWorldController {
@RequestMapping(
public ModelAndView
helloWorld() {
ModelAndView mav =
new ModelAndView();
wName(
ect(
return
mav;
}
}
你能够看到
，
@Controller
和
@Req
uestMapping
注解允许灵活的方法
名和签名。
在这上面的例子中的方法没有参数，
返回一个
ModelAndView
，
但还有其他各种（更好的）策略的
存在，会在本章后面介绍。
ModelAndView
，
@Controller
，和
@Reques
tMapping
是
Spring MVC
实现
的基础组成。
这章节文档会介绍这些注解如何普遍的在
Servlet
中应用。
@Controller
表明一个独有的类为一个控制器服务。
Spring
不要求你继
承任何控制器的基类或引
用
Servlet API
。然而，你仍能引用你需要的
Servlet
其他的功能。
@Contro
ller
注解以固定注解类形式来表明它的
角色。分发器就可以
通过该注解来获取这个类中带有
@RequestMapping
注解的方法。
你可以明确的注解控制器
bean
，
通过在分发器上下文中使
用标准的
Spring
bean
定义。然而，
@Controller
模式也允许自动侦测，
在类路
径中匹配
Spring
的公共侦测组件类并为他们自动注册
bean
定
义。要实现注解控制器自动探测
，需要在配置文件中加入探测组件。
A.
用
@RequestMapping
映射请求
使用
@RequestMapping
注解来映射就像
/appointments
这样
的
URLs
到整个类或特定的处理方法。一般来说，类级别的注
解映射特定的请求
路径到表单控制器上，而方法级别的注解只是映射为一个特定的
HTTP
方法请求（“
GET
”，“
POST
”等）或
HT
TP
请求参数。下这个例子显示
了在
S
pring MVC
应用中的一个控制器使用该注解：
@Controller
@RequestMapping(
public class
AppointmentsController {
private
final AppointmentBook appointmentBook;
@Autowired
public
AppointmentsController(AppointmentBook
appointmentBook) {
tmentBook =
appointmentBook;
}
@RequestMapping(method =
)
Public Map
return ointmentsForToday();
}
@RequestMapping(value=
public
Map
}
@RequestMapping(value=
public
AppointmentForm getNewForm() {
return new AppointmentForm();
}
@RequestMapping(method =
)
public String add(@Valid
AppointmentForm appointment, BindingResult
result){
if (ors()) {
}
ointment(appointment);
return
}
}
return
return ointmentsForDay(day);
@DateTimeFormat(iso=) Date day, Model
model) {
在例子中，
@RequestMappi
ng
在多处使用到。
第一种用法在类级别上，
< br>表明该控制器中的所有处理方法与
/appointments
< br>路径有关。
get()
方法
进行
进一步
@RequestMapping
细化配置
:
它只接受
GET
请求，<
/p>
也就意味着
只有
/appointmen
ts
路径下的
HTTP
GET
请求才调用该方法。
post
（）方
法有类似的细节，
通过
getNewForm
()
方法与
HTTP
方法和路径的定义
合
而为一，
/appointments
/new
的
GET
请求能够处理该
方法。
B.
支持的处理方法参数和返回类型
@RequestMapping
注解的处理方法拥有十分灵活
的签名。
大多数可以
不按顺序的使用。
?
请求或响应对象（
Servlet API
），选择任意指定的请求或响应
类型，例如
Servlet
Request
或
HttpServletRequest
。
?
会话对象（
Servlet
API<
/p>
）：
HttpSession
类型的。这
种类型的参
数强转成一个相应存在的
session
。所以，这样的参数绝不会为
空。
?
@PathVariable <
/p>
注解方法参数并将其绑定到
URI
模板变
量的值
上。
?
@RequestParam
对访问指定
Servlet
请求的参数注解
。参数值转
化成方法中声明的类型。
?
@RequestHeader<
/p>
对访问指定的
Servlet
的
HTTP
请求头参数注解。
参数值转化成方法中
声明的类型。
?
< br>ModelMap
丰富了隐式模型，对于
WEB
视图是可见的。
?
BindingResult
返回先前指令或表单对象的校验结果。
?
标记处理完成的表单状态，会触发
清理在处理器类型级别已被
@SessionAttributes
注解表明的会话属性。
接下来是处理器方法所支持的返回类型：
?
一个
Mo
delAndView
对象，这个模式隐含指令对象和参考数据存
取方法
@ModelAttribute
注解的结果。
?
一个模型对象
，
视图名则通过
RequestToViewNameTran
slator
把
请求转换为视图名称。
?
一个
Ma
p
对象来表示模型，而视图名则利用
RequestToVie
wNameTranslator
把请求转换为视图名称。
?
一个视图对象，
< br>该处理方法还可以以编程方式通过声明一个模型
参数丰富模型（见上）。
?
一个
String
对象来表示视图名，处理器中对于的方法也可以通
过声明一个
ModelMap
的参数来表示
model
。
?
空（
vo
id
）表示方法自己处理响应（通过声明一个
ServletR
esponse
或
HttpServlet-
Response
直接输出响应内容）或者通过
Req
uestToViewNameTranslator
把请求转化为
视图名（此方法不
用在处理方法中声明一个
response
参数）。
?
其他任何的返回类型被当做一个单
一的模型属性展示给视图，
通
过在方法级别指定
@ModelAttribute
来使用属性名（或基于返回
< br>类名的缺省属性名）。
IV.
视图
所有
W
EB
应用的
MVC
框架都提供了访问视
图的方法。
Spring
提供了
视图解
析器，使你提交模型到浏览器而无需绑定特定的视图技术。不同
一般的，
Spring
允许你使用
JSPs
，
Velocity
模板和
XSL
T
等多种视图。
Spring
处理视图最重要的两个接口是
ViewResolver
和
View
。
ViewRe
solver
接口在视图名称和真正的视图之间提供映射；而
V
iew
接
口访问请求准备并提交请求给其中一种视图技术。
A.
用视图解析器接口解析视图
在
Spring WEB MVC
处理
器中所有处理器方法必须解析一个逻辑视图
名，
无论是显示的还
是隐式的。
Spring
中的视图通过被视图解析器解析
后的逻辑视图名来访问。
Spring
有很多
视图解析器。
ResourceBundleViewRes
olver
检查
ResourceBundle
定义下的
bean
名称，并解析每个视图。它用属性值
[
视图名
].(class)
作为视图类，属
性值
[
视图名
].url
作为视图
url
。
B.
视图重定向
正如先前提到的，一个控制器一般返回一个逻辑名，解析器再将其
解析成特定的视图
技术。对于如
JSPs
这样通过
Ser
vlet
或
JSP
引擎来
处理视图的技术来说，它的解决方案通常要结合
InternalResou
rceViewResolver
和
InternalReso
urceView
，通过
d()
方法或
者
e()
方法发布内部转发或包含
指令。
对于其
他诸如
Velocity
,XSLT
的视图技术，视图本上直接输出内容到响应流。
<
/p>
有时在视图渲染前发布
HTTP
重定向指
令返回客户端是会发生的，当一
个控制器已经被
POSTed<
/p>
的数据调用，并且响应已经委托给另一个控制
器（例如成功提交表
单）。在这种情况下，一个常规的内部转发将意味
着其他控制器也可能会看到相同的
POST
数据，如果它与其他预期的数
据混
淆是个潜在的问题。
消除用户多次提交表单的可能性是另一个显示
结果前执行重定向的原因。在这种情况下，浏览器会先发送原始的
POS
T
；
得到响应后重定向到不同的
URL
；
最后浏览器会显示
GET
后来在重定
向响应指定的
URL
。这样一来，从浏览器看来，当前页没有反射
POST
的结果而是
GET
的。最后影响用户没有办法通过刷新
，偶然地重
POST
同样的数据。刷新出的是
< br>GET
的结果页，不是重发的原
POST
数据。
C.
重定向视图
控制器响应结果的一种强制重定向方法是该控制器创建并返回一个
Spring
的重定向视图实例。
在这种情况下，
分发器
不能使用正常的视图
解析机制。因为它已经转发给视图了，分发器只能知识视图去完成它
的
工作。
重定向发出
direct()
指令使其作为
HT
< br>TP
重定向返回客户端浏览器。所有的模型参数被作为
H
TTP
查询参数。
这意味着模型只能包含一个对象
（通常字符串和对象会转化成一个字符
串表示形式），能很好的转换成一个正
文
HTTP
查询参数。
如果你使用了重定向视图并且视图是由控制器自身创建的，建议你
配置重定向
的
URL
注入到控制器，
这样他没有写
在控制器中却能根据视
图名在上下文中配置。
D.
重定向：前缀
< br>当重定向视图很好的起作用时，
如果控制器自身创建了重定向视图，
事实上难免控制器知道一个重定向发生。
这真的很不理想并且关系太紧
密了。控制器不应该关注响应如何处理。通常只有在视图名被注入时它
才开始操作。
特殊的重定向：前缀能让你完整上述问题。如果
带有前缀的视图名
返回时，
UrlBasedView-Res
olver
（所有的基类）会识别出它当作一个
重定向所需的特
殊指示。剩下的视图名会被当作重定向的
URL
处理。
效果是相同的，如果控制器已返回重定向视图，但现在控制器本身
能简单地依据逻辑视图名进行操作。
如同
redirect:/my/response/con
的一个
逻辑视图名会重定向当前相关的
servlet
上下文，
而名为
redirect:/some/arbitrary/
会重
定向到绝对路径的
URL
。最重要的是，只要像其他逻辑视图名一样注入
重定向视图名到控制器，控制器
不会意识到重定向的发生。
E.
视图技术
Spring
为
JSP
和
JSTL
提供了对拆箱即用的解决方案。在版本
2
.0
中使用
JSP
和
< br>Spring We-b MVC
时，
Spring
为处理表单提供了一套全面
的数据绑定标签。
每个标签提供了与
HTML
相对应的标签属性集的支持，
使标签能熟悉且直观的使用。
HTML
自生
成标签符合
HTML
4.01/XHTML1.
0
规范。
-
-
-
-
-
-
-
-
-
上一篇：灌装机的发展史中英文对照资料外文翻译文献
下一篇：几种常用在线翻译工具的对比研究