Spring的web框架（外文翻译） ㊣ 精品文档 值得下载

，中文译文包是框架的最基础部分，并提供依赖注入特性来使你可管理容器功能。

这里的基础概念是，它提供模式来消除对程序性单例的需要，并允许你从程序逻辑中分离出依赖关系的配置和描述。

构建于包上包，提供了种框架式的访问方式，有些象注册。

包的特性得自包，并添加了文本消息的发送，通过比如资源串，事件传播，资源装载的方式和的透明创建，如通过容器。

包提供了的抽象层，它可消除冗长的编码和解析数据库厂商特有的代码。

该包也提供了种方法实现编程性和声明性事务管理，不仅仅是针对实现特定接口的类，而且对所有的。

包为流行的关系对象映射提供了集成层，包括，和。

通过包，你可与所有提供的其他特性相结合来使用这些对象关系映射，如前边提到的简单声明性事务管理。

的包提供与联盟兼容的面向方面编程实现，允许你定义，如方法拦截器和切点，来干净地给从逻辑上说应该被分离的功能实现代码解耦。

使用源码级的元数据功能，你可将各种行为信息合并到你的代码中，有点象的。

的包提供了基本的面向的综合特性，如功能，使用监听器的的初始化和面向的。

当与或起使用时，这个包使可与其他框架结合。

的包提供了面向应用的实现。

的实现不仅仅是种实现，它提供了种代码和的清晰分离，这使你可使用框架的所有其他特性，如校验的框架是围绕分发器设计的，将请求分发到不同的处理器，框架还包括可配置的处理器映射，视图解析，本地化，主题解析，还支持文件上传。

缺省的处理器是个简单的控制器接口，这个接口仅仅定义了，方法。

你可以实现这个接口生成应用的控制器，但是使用提供的系列控制器实现会更好些，比如和。

应用控制器般都从它们继承。

注意你需要选择正确的基类如果你没有表单，你就不需要个。

这是和的个主要区别。

你可以使用任何对象作为命令对象或表单对象不必实现个接口或从个基类继承。

的数据绑定相当灵活，例如，它认为类型不匹配这样的应该是应用级的验证，而不是系统。

所以你不需要为了处理无效的表单提交，或者正确地转换字符串，在你的表单对象中用字符串类型重复定义你的业务对象属性。

你应该直接绑定表单到业务对象上。

这是和的另个重要不同，是围绕象和这样的基类构建的，每种行为都是它们的子类。

和相比，将对象细分成不同的角色它支持的概念有控制器，可选的命令对象或表单对象，以及传递到视图的模型。

模型不仅包含命令对象或表单对象，而且也包含任何引用数据。

但是，的将所有的这些角色都合并在个单独的对象里。

允许你在表单中使用现有的业务对象，但是只能把它们定义成不同类的属性。

更重要的是，在运算和表单赋值时，使用的是同个处理请求的实例。

因此，引用数据也需要被定义成的属性。

这样在个对象就承担了太多的角色。

对于视图的视图解析相当灵活。

个控制器实现甚至可以直接输出个视图作为响应，这需要使用返回。

在般的情况下，个实例包含视图名字和模型映射表，模型映射表提供了的名字及其对象比如命令对象或表单对象，引用数据等等的对应关系。

视图名解析的配置是非常灵活的，可以通过的名字，属性文件或者你自己的来实现。

抽象的模型映射表完全抽象了表现层，没有任何限制或者其它的技术任何表现层都可以直接和，却不会使你的相关的代码受到影响。

更好的是，相关的代码可以完全和代码。

这对于处理那些没有用或实现的功能非常有用。

避免绑定特殊的技术，允许的实现策略。

虽然非常强大，灵活，开源而且免费，但它还是使用了自己的特定的。

此外有人也许会争辩更轻便而且在不需要复杂的映射策略的应用中使用也很优秀。

能够选择的话，使用标准或抽象的来实现主要的应用需求，通常是更好的。

尤其，当你可能会因为功能，性能或其他方面的原因而需要切换到另个实现的时候。

举例来说，对事务和异常的抽象，以及能够让你轻松交换和对象实现数据访问功能的机制，这两个特性可以让你在不牺牲性能的情况下，在你的应用程序中隔离的相关代码。

处理的高层次的代码不需要知道的具体实现。

这个方法可以很容易使用方案互不干扰地实现数据访问层比如在些地方用，些地方使用，其他地方使用，有利于处理遗留下来的代码以及利用各种技术的长处。

提供了致的事务管理抽象。

这个抽象是最重要的抽象之，它有如下的优点为不同的事务提供致的编程模型，如数据库层和提供比大多数事务更简单的，易于使用的编程式事务管理整合数据访问抽象支持声明式事务管理传统上，开发者有两个事务管理的选择全局事务或局部事务。

全局事务由应用服务器管理，使用。

局部事务是和资源相关的例如，个和连接关联的事务。

这个选择有深刻的含义。

全局事务可以用于多个事务性的资源需要指出的是多数应用使用单事务性的资源。

使用局部事务，应用服务器不需要参与事务管理，并且不能帮助确保跨越多个资源的事务的正确性。

全局事务有个显著的不利方面，代码需要使用个笨重的部分是因为它的异常模型。

此外，的通常需要从获得，这意味着我为了需要同时使用和。

显然全部使用全局事务限制了应用代码的重用性，因为通常只在应用服务器的环境中才能使用。

使用全局事务的比较好的方法是通过的容器管理的事务声明式事务管理的种形式区别于编程式事务管理。

的不需要任何和事务相关的查找，虽然使用本身肯定需要使用。

它消除大多数不是全部书写代码控制事务的需求。

显著的缺点是绑定在和应用服务器环境上，并且只有我们选择使用实现业务逻辑，或者至少处于个事务化的外观后才能使用它。

有如此多的诟病，当存在其它声明式事务管理时，不是个吸引人的建议。

局部事务容易使用，但也有明显的缺点它们不能用于多个事务性资源，并且趋向侵入的编程模型。

例如，使用连接事务管理的代码不能用于全局的事务中。

解决了这些问题。

它使应用开发者能够使用在任何环境下使用致的编程模型。

你可以只写次你的代码，这在不同环境下的不同事务管理策略中很有益处。

同时提供声明式和编程式事务管理。

使用编程式事务管理，开发者直接使用事务抽象，这个抽象可以使用在任何底层事务基础之上。

使用首选的声明式模型，开发者通常书写很少的事务相关代码，因此不依赖或任何其他事务。

集成。

模型映射表仅仅将数据转换成合适的格式，比如请求属性或者模版模型。

实现的可扩展性许多团队努力争取在技术和工具方面能使他们的投入更有价值，无论是现有的项目还是新的项目都是这样。

具体地说，不仅有大量的书籍和工具，而且有许多开发者熟悉它。

因此，如果你能忍受的架构性缺陷，它仍然是层个很好的选择。

和其它框架也是这样。

如果你不想使用的框架，而仅仅想使用提供的其它功能，你可以很容易地将你选择的框架和结合起来。

只要通过的启动个的根应用上下文，并且通过它的属性或者的各种帮助方法在或的中访问。

注意到现在没有提到任何具体的，因此这里也没有提及如何集成从层的角度看，你可以仅仅把作为个库使用，根应用上下文实例作为入口。

所有你注册的和的服务可以在没有的下被访问。

并没有在使用方法上和或竞争，它只是提供单框架所没有的功能，从的配置到数据访问和事务处理。

所以你可以使用的中间层和或者数据访问层来增强你的应用，即使你只是使用象或事务抽象这样的功能。

框架的特点如果仅仅关注于方面的支持，有下面些特点清晰的角色划分控制器，验证器，命令对象，表单对象和模型对象分发器，处理器映射和视图解析器等等。

直接将框架类和应用类都作为配置，包括通过应用上下文配置中间层引用，例如，从控制器到业务对象和验证器的引用。

可适应性，但不具有强制性根据不同的情况，使用任