基于微信移动端电商网站的实现外文翻译资料

 2022-09-06 15:29:08

英语原文共 19 页，剩余内容已隐藏，支付完成后下载完整资料

Expert Spring MVC and Web Flow

在进一步探讨Spring MVC的内部结构之前，了解一下如何构建典型的Spring MVC是非常有必要的。本章将回答业务逻辑应置于何处、什么是正确的抽象层次等问题。我们将完整地展示Spring MVC Web应用程序，更好地解释Spring MVC在整个架构中所扮演的独特角色 及其适用场所。

精通一个新框架需要的不仅是钻研其API。分析并认识Spring MVC Web应用程序的完整架构会为设计框架本身提供一些线索。这样就使得你可以有更深层次的认识，并在构建应用程序时做出更合理的选择。

3.1 抽象层

Spring MVC应用程序可以细分为一系列的层。我们把层（layer）视为在某一应用程序内按照关注点划分的离散的，正交的区域。例如，所有的持久代码对于视图呈现代码来说都被看作是单独的一层。层是应用程序内部的抽象，而接口为这些层提供了互相作用的约定。有些层正好被隐藏，只能由紧临它的上一层使用。相反，系统中最重要的层（领域模型本身）几乎跨越了系统中的所有其他层。

层有概念上的边界但是未必在物理上是隔离的。通常，对于一个Web应用程序来说，所有层都部署在同一个虚拟机上。关于应用程序发布的详细讨论请查阅 Rod Johnson所著的 Expert One-on-One J2EE Design and Development ( Wrox.2002 ) 。

层的思想可以帮助理解整个应用程序的流程。如果将应用程序的各层组成一个蛋糕（蛋糕一层一层地叠放），这可以更容易阐述应用程序的组织结构。拿蛋糕打个比方，“向下至持久层”和“向上返回到用户界面”，给人一种垂直的方向感，图3-1解释了Web应用程序中常见的、高度概括的层。

一般而言，持久层的功能在底部，而用户界面在顶部。中间层放什么？怎么组织？这就是本章的主题。我们使用蛋糕的比喻来解释架构。

进一步说，一般的Spring MVC应用程序至少有5个抽象层，以便开发者编写代码。这些层是: 1用户界面 2 Web 3服务 4领域对象模型 5持久。

有读者可能注意到了，一些常见的应用程序元素（如事务管理或者安全）都不在上述所列范围内。如果你熟悉Spring框架及其在面向方面编程（AOP)上大量的使用，就不会感到奇怪。比如事务管理，它被看作是一个系统的透明方面而不是一个层。

领域模型垂直跨越了所有的其他层。这是由于其他层都依赖于领域模型，它是唯一横切其他层的层。

3.1.1层隔离

分离各问题域，如持久、Web向导以及用户界面，将其放入不同的层，这样便创建了灵活的、可测试的应用程序。每层的实现各不相同，这就提高了应用程序的灵活性。降低应用程序之间的耦合性有利于独立测试应用程序的每一部分，从而提高应用程序的可测性。

这种隔离通过尽量减少层间依赖的数最来实现。一个层自身之上的依赖越少，则改变它的开销就越小。最佳实践只被其他一两个层所需要是一个层。要避免应用程序的很多不同部分需要同一个层。

至少有两种方式可以避免过度依赖。如果一个层使用了太多的层，就要考虑新建一个抽象层来包装之前所有的交互。另外，如果一个层滲透到许多层，就要考虑那个层是否本身就是系统的一个方面。如果这个功能需要透明地应用到系统的大部分，使用Spring的AOP功能就可以移除这些代码的显式依赖。

有一个重点要记住，将应用程序分层的最大好处之一就是能得到解耦的设计。当发现应用程序的层过度侵入时，应将其重构至其他抽象或者使用AOP。这将使应用程序灵活、可测试。

3.1.2 Java接口作为层的约定

Java接口是能够使用层构建应用程序的关键。接口就是层的约定，因此在要求正确使用层的同时，隐藏实现及其细节就更容易了。

接口提供了低耦合，其好处早已众所周知，但因为仍需具体类型的实例化，这种优势还未充分体现。在Spring或者其他依赖注入框架出现之前，实现能够抽象的许诺不曾完全兑现。是Spring帮助接口真正地闪光，因为它替代了应用程序代码来处理对象的创建。

在大的组织设置中，把接口看作层之间的约定是非常有帮助的。协调大项目所需的诸多资源并不容易，层间的集成极少恰到好处。因为轻量级的特性，接口有助于提高团队的开发速度。开发者根据接口开发，而接口的实现可同时持续地构建和测试。

在实用层面，Spring框架尤其适合使用接口。它的A0P设施围绕JDK代理建立，使扩展一个接口实现具有附加服务变得简单。

使用接口定义组件间的交互可以使单元测试变得非常简单。使用框架，如EasyMock或者，只需少量的代码就能容易地创建接口的模拟实现，并可以在测试对象及其与合作者的交互的时候使用这些模拟实现。虽然EasyMock和jMock都可以创建类的模拟而非接口的模拟，但是它们需要运行时生成字节码，而且还有一些使用基于接口模拟时的没有的问题。

用接口连接层还有一个好处：能减少编译时间并创建更多模块化的构造。具体的实现类可以改变而不需要对依赖于它的客户端重新编译（因为客户端物理上不需要对具体类的物理依赖）。对于大的系统，在这构建和部署时是非常有用的。

使用接口可以使系统更灵活，即可以在启动时甚至在应用系统运行时选择它们的实现。由于客户端根据接口编译，因此实现类可以在运行时被换入（swap in)和换出（swap out)。这就创建了一个非常动态的系统，进而提高灵活性并降低耦合，许多系统利用了这种能力，如Spring本身。

总的来说，每层都作为接口暴露。接口提供了抽象层，因而在不影响应用程序其他部分的前提下改变层的实现就变得很简单了。

3.1.3 Spring MVC应用程序中的层

本节讨论了典型Spring MVC应用程序中的每个主要层。同时也会讨论不同于该设计思路。有些讨论涉及Spring MVC接口或者类的。不要担心，我们会在后面的章节中详细解释每一个主题。

1 .用户界面层

用户界面层会负责将应用程序呈现给最终用户。该层将由Web层生成的响应呈现到客户端请求的表单.例如，手机通常需要WML或者至少使特殊格式的XHTML其他客户端可能需要用PDF作为其用户界面。当然，浏览器需要呈现成XHTML的响应。我们把用户界面呈现层从Web层分离出来，以便尽可能多地复用Web层。

用户界面层一般是最上层。理论上，这意味着它是字节发送给客户端之前的过程链的最后一层。至此，已经执行了所有业务逻辑，提交了所有事务并释放了所有资源。

这种情况下，作为最后一层是件好事，用户界面层会负责呈现发送给客户端的字节。Web应用程序中的客户端是远程的，通过不可靠的网络连接起来。字节的传输有可能放缓、重复甚至停止。用户界面层与其他的层保持隔离是因为我们希望系统继续处理其他请求，使用有价值的资源（比如数据库连接），而不必等待网络连接。换言之，为客户端呈现响应的动作与聚集响应的动作是相互分离的。

将用户界面隔离到自身层还有一个现实原因，那就是存在许多呈现用户界面的工具包，比如 JSP、Velocity、FreeMarker和XSLT (所有这些Spring都支持）。将UI关注点置于其自身层之后可以允许改变呈现技术而不影响其他层。系统的其他层对选择呈现工具而言应当是隐藏的。要将特定的工具包直接绑定到系统上，选择非常多，每一种选择都有其优缺点。

有UI专家的团队会因为分离该层而获益匪浅。与开发者相比，UI设计师一般都使用不同的工具集并专注在不同的关注点上。根据其需要提供一个专门的层可避免他们去了解系统大部分的内部细节，这在开发的原型及接口设计阶段是尤为重要的。

bull; Spring MVC的用户界面层

Spring MVC用一些关键接口解决UI问题，做得比较成功。org.Springframework.web. servlet.View接口呈现了Web应用程序的视图或者页面，它负责将客户端请求操作（响应模型） 的结果转换成一个客户端可见的表单。

View接口是完全通用的，没有任何具体的视图呈现依赖。每种视图技术都提供了该接口的实现。 Spring MVC本身支持JSP、FreeMarker、Velocity、XSLT、JasperReports、Excel和PDF。Org.springframework.web.servlet.ViewResolver提供了一个有用的间接层，ViewResolver提供了视图实例及其逻辑名称的映射。例如，一个文件名为/WEB-INF/jsp/onSuccess.jsp的JSP页面通过“ success” 名称被引用，这就解耦了实际的视图实例和代码引用。它甚至可以将多种 ViewResolver串连在一起来进一步创建灵活的配置。

bull;依赖

视图层一般依赖于 领域模型（见以下探讨）。尽管并不总是这样，但是这样非常有利于直接暴露和呈现领域模型。由于视图直接访问领域对象，因此使用Spring MVC处理表单非常便利。

例如，通常用领域模型的实例来填充该模型。该视图技术通过直接查询领域模型实例来呈现页面。

有些人可能会认为它在系统中创建了不必要的耦合。我们相信分离两层带来的不便大于这种方法的好处。例如，Struts为其模型bean专门使用一个类层级，与领域模型完全分离。这就创建了多余的平行类层级，从而白费许多精力。通常系统没有那样解耦是由于针对视图的类与领域的类，几乎一一对应。

简言之，Spring MVC推荐集成领域类到视图。我们认为这是可行的，但这不是强制或者必需的。

bull;小 结

用户界面层（也称作视图）负责为客户呈现输出，一般来说，这对Web应用程序意味着XHTML，但是Spring MVC支持文本和二进制输出的很多种不同的视图呈现技术。关键的接口是 org. springframework.web.servlet.View（呈现单独页面）和 org.springframework. web.servletViewResolver（提供视图和逻辑名称的映射）。

2. Web层

导航逻辑是由Web层处理的两个重要功能之一，它负责按照正确的次序引导用户到达正确的页面视图。它可以简单到一个URL对应一个页面，也可以复杂到使用一个完整的工作流引擎。

管理用户体验和浏览站点是Web层独有的职责。贯穿本章的许多层大多呈现无状态角色。不过Web层一般会包含某种状态，帮助指引用户直达正确的目标。

一般在领域模型和服务层没有任何逻辑导航，这是Web层的一个独特领域这就创建了更为灵活的设计，因为单独的领域模型功能可以有许多结合方式，以产生很多不同的用户体验。

Web层第二个主要的功能是提供服务层和HTTP世界的黏合剂。它成为薄薄的一层，委托给服务层以协调业务逻辑。Web层关注请求参数、HTTP会话处理、HTTP响应代码以及与Servlet API的相互作用。

HTTP领域由请求参数、HTTP首部以及cookies组成。这些方面不是针对具体业务逻辑的，因而保持了与服务层的独立性。Web层对业务逻辑隐藏了Web领域的细节。

把Web关注从业务逻辑中移出来，这会使得核心逻辑非常容易测试。不必担心在测试业务层的时候要设置请求变量、会话变量、HTTP响应代码或者类似的其他参数。同样，当测试Web层时，可以轻松地模拟业务层，并只需考虑如请求参数这样的问题。

从服务层分离Web关注同样意味着系统可通过多种方法输出相同的业务逻辑。这就减少了代码的重复并允许系统快速简便地添加连接机制，如HTTP、SOAP或者XML-RPC。 Web层只是成为了另外一个客户连接机制，可访问核心业务功能，但是没有直接实现这些功能。

例如，Web层的实现可以像servlet—样的简单。这些servlet为服务层把请求参数转换成有意义的对象，接着调用服务接口上的方法。此外，Web层还负责为最终用户将业务异常转换成适当的错误信息。

更高层次的框架，如Spring MVC和Tapestry. 为原始请求参数和业务逻辑层提供了复杂的转换机制。例如， Spring MVC将请求参数映射成业务逻辑可以处理的POJO。 Spring MVC还为处理请求、构建处理请求的方式实现了复杂的工作流，并使扩展变得简单。

Web层的实现有两种主要类型：请求/响应框架和组件框架，请求/响应框架被构建成了直接与 Servlet API和HttpServletRequest以及HttpServletResponse相互作用。这类框架被认为拥有推模型，因为用户代码将编辑结果并将其推出去呈现。Spring MVC被认为是一个请求/响应框架。

其他框架采用了不同的方法处理Web请求。有些框架如Tapestry和JSF (JavaServer Faces) 被认为是基于组件的。这些框架不仅试图隐藏Servlet API，而且使编写Web程序感觉上像编写Swing 应用程序。那些框架本质上是事件驱动的，因为组件响应源自Web层的事件。

这两种类型的编程模型各有其优点和缺点。我们相信Spring MVC是一个很好的平衡。它提供了用于处理请求的丰富的实现层次结构，从极其基本的到极其复杂的。可以选择所希望耦合Servlet API的程度。使用基本的Spring MVC类可暴露Servlet API，而使用Spring Web Flow或者ThrowawayController，则Servlet API可以完全被隐藏。对于Spring框架，开发者可以选择针对具 体情况的最好办法。

bull;依 赖

Web层依赖服务层和领域模塑。Web层将它的处理委托给服务层，并负责转换从Web发送进领域对象且足以用来调用到服务层的信息。

bull; Spring M

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[146747]，资料为PDF文档或Word文档，PDF文档可免费转换为Word

原文和译文剩余内容已隐藏，您需要先支付 30元 才能查看原文和译文全部内容！立即支付

以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。

您可能感兴趣的文章