对Spring的十大常见误解

在OnJava上看到的文章,觉得不错,试着翻了一下,希望对大家有帮助.

原文链接  http://www.oreillynet.com/onjava/blog/2006/08/ten_common_misconceptions_abou.html

       从对Spring框架的一些批评甚至攻击（不论公正与否）中可以归纳出对这一框架的十个常见的误解。

对Spring框架还不熟悉的人来说，可能需要先解决一些刚开始接触Spring时遇到的问题。实际上，我们编选的这个清单来自于培训Spring的新用户时总结的经验和查看Java开发社团中的讨论和论坛中内容。我们的目的对这些议题提供一些参考意见，以便在你的下一个项目中决定采用Spring时更加胸有成竹。
误解1：Spring不是轻量级的，它打算做所有的事情并且变得越来越庞大和臃肿。
Spring的主要目标是使基于POJO的轻量级开发成为可能。作为开发人员，你应当能够专注于特定领域的业务逻辑而不是基础结构问题和费解的项目合同，应当能够依赖于框架来处理集成方面的事情。然而，当开发企业级应用时，却不可避免地要和很多这类事情打交道。因此，在某种意义上，Spring确实打算做所有的事情，这些事情正是企业级开发人员期望企业级框架完成的。Spring支持如此众多的企业级服务和第三方产品，乍看起来确实有些庞大和臃肿，但是，为了给企业级软件开发提供一个综合的集成平台并同时支持全方位的基于POJO的开发，Spring框架从一开始就设计为非侵入式的和模块化的，你可以并且应该对特定的项目只选择必需的东西，而当需求演变时，你可以不断地增加（或去除）模块，Spring开发团队强调任何事情应尽可能简单，这不但适用于Spring本身，更适用于基于Spring构建的应用。
误解2：Spring对简单应用的开发过于强大了（杀鸡用牛刀）。
如上一点所述，Spring框架可以帮助你保持事情应尽可能简单。你可以在刚开始时仅仅使用需要的部分，当需求更加明晰时再改造和扩展应用，这样一种（开发）环境对促进简单应用的开发是很有意义的，首先，即使是简单应用通常也需要一些企业级服务，如事务性的数据库访问，在这种情况下，最简单的选择也许就是依赖于Spring提供的集成式的数据访问和声明式的事务管理；此外，简单的（应用）原型可能以各种方式转变为成品应用，如果由你来负责这样的应用，你会心仪于一个轻量级的然而是可扩展的框架来处理这些需求。
误解3：Spring不能扩展到处理大型的应用。
Spring已经被全球数百家最大的企业使用在非常大的应用中，在企业级开发环境中很好地使用着Spring框架以满足银行、政府部门、航空运输业的应用系统的需求。
Voca公司就是一个例子，该公司为超过百分之七十的英国人口提供家庭帐单支付服务，并提供英国超过百分之九十的薪水支付服务，依赖于Spring，在2005年就处理了超过50亿个交易，最高日交易量达7200万。
其它能证明其对开发效率和性能的提升的大型基于Spring的应用还有由Accenture完成的法国税务部门的一个在线系统和欧洲专利局的一个企业级应用（据SpringOne 2006 主题演讲，安特卫普，比利时）。
误解4：Spring强迫你使用还处在实验阶段的面向方面的编程（AOP）。
Spring的一些强大功能得力于面向方面的编程或AOP技术（见第三、四章），但你总是可以选择是否使用这些特殊的特性，此外，Spring 2.0已经显著地改进了与AspectJ的集成，这意味可以有越来越多的选择使用AOP的方式。很多用户通过使用
4000
Spring的基于代理的AOP已经对核心概念驾轻就熟，而当需要更为强大的功能时就开始使用AspectJ了。
 在让冗长的说教左右你作出决定之前，有一些事情是必须知道的。首先，Spring基于代理的AOP依赖于对JDK的动态代理机制的使用，这意味着这种功能实际上是被Java核心语言所支持的；其次，AspectJ是经过多年研究形成的产品，现在已经成为相当完备的事实上的标准；第三，AOP特别专注于面向对象编程的一个特定的局限性因而应当被看做一种补充性的而不是革命性的技术。
传统的面向对象编程不能模块化特定的“方面”因而导致代码重复和直交逻辑（如审计、安全性等）的散乱。一旦你越过了最初的学习曲线（其实是非常容易的），AOP是一个非常自然的解决这些问题的方式。例如，在一个基于Spring的应用中，你可以为整个服务层提供事务管理而不需要修改任何代码。这就意味着应用更加灵活并且易于维护，同时保持代码纯粹地专注于业务逻辑。有了这些和其他类似的能力，你就会和越来越多的开发者一样，更加愿意开始AOP的实践。
误解5：Spring取代了Java 企业版(JEE)。
这一点是关于Spring的最大的误解之一并且是最大的误导之一。实际上，Spring的主旨在于JEE的集成，Spring相对于传统的、重量级的、基于EJB的组件模型提供了一个值得关注的替代物，同时得力于其它JEE标准的全部功能。它的一个动机是简化JEE API的使用，以使开发者不必被迫重复编写大量的代码；另一个动机是鼓励解除应用程序代码和JEE服务之间的耦合。Spring提供了一致的方式以提高产能，同时提供了适当的抽象以提高灵活性。
Spring对JEE API的集成支持包括：
l       Java Message Service(JMS)
l       Java Management Extensions(JMS)
l       Java Transaction API
l       JEE Connector Architecture(JCA)
l       Java API fro XML-based Remote Procedure Calls(JAX-RPC)
l       JavaMail
l       Java Naming and Directory Interface(JNDI)
l       和Enterprise JavaBeans(EJB)，包括版本3。
对一些很重要的Java标准版的技术如JDBC和RMI以及JEE 版本5中的新增的Java Persistence API(JPA或称EJB版本3持久化规范)Spring也提供了支持。Spring一致性地使用同样的途径来集成较完善的第三方产品，如Hibernate，iBATIS，Quartz，Hessian等等。
Spring的JEE集成从未基于“最小公分母”方式，而是尽最大努力保留访问底层技术的最大功能。换句话说，虽然意识到百分之八十的情况下只需使用百分之二十的功能，剩下的百分之八十的功能需要时仍然是可用的。
对这一问题的深入探讨，可参考Rod Johnson 和 Juergen Hoeller所著《Expert One-on-One J2EE Development without EJB》一书。
误解6：Spring和EJB是互斥的技术。
在前一点中，我们把Spring描述为EJB的“一个值得关注的替代物”，然而，Spring促进了选择性-包括选择使用EJB。Spring提供了实现EJB的支持类并使其可以访问Spring容器中的可管理的Bean。Spring也提供了一个可配置的代理机制，使得EJB的客户端代码仅依赖于简单的业务逻辑接口。EJB远程访问的细节，JNDI查找和相关的异常都隐藏于代理之后并由Spring进行管理。这种抽象在集成基于EJB的遗留代码和新开发的基于POJO的代码时是十分有用的，因为客户端不再关心这些细节，这种方式同时提供一条方便的从EJB到POJO的移植路径。有趣的是，如果你选择使用EJB3和与其相关的基于POJO的持久化模型(JPA)，你会高兴地发现从基于Spring的应用进行移植比从基于较早版本的EJB应用进行移植要顺畅得多，而且，利用Spring，你可以得到JPA的所有优点而不必使用EJB 3的其它特性。
误解7：Spring不能象EJB 3那样利用Java 5 的标注特性。
Pitchfork项目，是Spring框架的一个补充，支持JSR-250和JSR-220(EJB 3)标注的一个子集，该项目是Interface21和BEA公司的一个合作成果，在Apache 2.0许可下发布。它不但提供了WebLogic的EJB 3实现的基础，也使得通过Spring框架扩展EJB 3的编程模型成为可能。
Spring 2.0的核心模块提供了对JPA(EJB 3 的持久化机制)的完整的集成的支持，包括其标注，还增加了对@AspectJ类型的标注的支持。其它对比标注的支持包括事务管理、JMX配置和依赖校验。
误解8：对大型的应用，Spring的XML配置文件会难以维护。
如果不进行适当的管理，Spring的XML文件确实会变得难于编辑和容易出错，对此我们会指出如何利用正确的工具和技巧来解决遇到的一些具体问题：
易于出错：使用合适的工具是必不可少的，一个XML文件编辑器可以借助于DTD或XML Schema Definition(XSD) 提供代码填充和校验。Spring 2.0主要的特点之一就是使用了基于XSD的配置(文件)，从而给（XML）编辑器提供了更多的信息。支持Spring的IDE，如InterlliJ和Eclipse的Spring插件，提供了更多的功能，如类名的填充和在bean定义中获得属性的提示等，如果你可以从一个下拉列表中选择名称，就会节省时间并且不会产生任何输入错误。
难于通查
XML文件应当拆解开来，以对应于应用系统模块的结构，就像代码一样，合理的做法是把相关的配置信息集中在一起并将不相关的部分清晰地分开。
对简单易变的属性（的维护）过于繁琐
某些键/值对应外置于属性文件中，这样就避免了每当这些简单的属性需要修改时都要修改XML配置文件。Spring提供了配置选项，使得当bean的定义中需要这些属性时就能找得到（见第5章）。
过多的重复定义
当通用的属性在大量的相关项目中都要进行设置时可以通过Bean定义的继承减少重复，例如：单一的“dataSource”bean的定义可以满足很多数据访问bean对其的依赖，在此例中，只需一行（配置），一个抽象的父类定义就能提供这种共享属性。
过于宽泛
Spring 2.0中一个主要的增强就是支持XSD和领域特定的名字空间，这就能够为很多常见的配置项目提供更准确的格式，这也为特定领域的bean定义提供名字空间或和其它框架的集成提供了方便。
误解9：Spring利用反射完成所有事情，因此会很慢。
Spring并不是完全通过反射做所有的事，但确实大量使用了反射。因此我们应澄清Spring中反射的作用而且应探讨一下通常情况下反射的性能特征。
Spring利用反射实现其依赖注入，但重要的是要知道这只发生在配置阶段（此时bean被关联起来）。从运行时的性能方面看，这与你特意地在Java代码中设置这些依赖没有什么区别。
Spring通过标准的JDK动态代理对象在其AOP框架中使用反射，这些代理对象是特定地配置在粗粒度的服务层上，提供诸如事务管理、安全以及通过远程访问输出对象，如果对代理对象的方法的调用和执行涉及到网络和/或数据库访问，那么由于使用反射代理对性能造成的影响是可以忽略不计的。
在任何情况下，对性能产生影响的论断都应该基于相应的基准而不是主观判断或道听途说，如果你使用的是Java 1.3版本，那么有些关于反射的传统说法也许是对的，然而在Java 1.4版本中，反射API的性能提高了2,000%。
误解10：Spring 的MVC比较复杂，不象Spring的其它部分那样简单。
通过基于接口的设计，Spring MVC的可配置性和可扩展性都十分强大，它利用了成熟的（well-established）设计模式，象策略模式（如ViewResolver）和模板方法模式（如SimpleFormController）。不幸的是，很容易将可配置性和可扩展性误认为是复杂性。对Spring中的所有东西，你可以并且应该使用需要的部分，但如果花些时间去学习一下还有什么东西可用将会对你大有益处。你将会乐于惊讶地发现每一个Spring的MVC模块是如此简单和定义完好，每一个相关的单元都着重于实现HTTP请求的生命周期和生成页面过程中的一小部分功能，这就促进了业务逻辑和表现逻辑的解耦，进而使应用更加功能强大而灵活。一旦你在一个项目中使用了Spring MVC框架，你将会欣赏其强大和易用。用Spring MVC实现一个小而简单的项目确实是非常容易的。