spring揭秘 笔记一 spring框架的由来

spring框架的由来

在spring揭秘书中，作者举了一个列子来描述spring框架出现的必然性。
在中世纪的欧洲，重骑兵所向披靡，各国家都需要养一只精装的重骑兵来宣扬国家的强大，但是一直重骑兵的装备维护所需的花费却可以组装多只补兵军队，一些小国为了养重骑兵消耗国力颇多。这时候装备精简而速度更快更有优势的轻骑兵就应运而生了。
在早期的J2EE平台开发实践过程中，很多的公司都盲目的推崇一种高热度技术，例如大火的EJB，EJB是使用J2EE平台各项服务的一种方式，但不是唯一的方式。对于分布 式系统来说，使用EJB在某些方面确实可以带给我们很大的收益，但并不是所有的J2EE应用都要用于分布式环境。如果不分场景地滥用EJB，则会出现很多问题

• 使用EJB，通常也就意味着需要引入拥有EJB Container的应用服务器（J2EE Application Server）
  的支持，比如BEA的WebLogic或者IBM的WebSphere，而这往往也就意味着高昂的授权费用。
  虽然开源的JBoss等应用服务器也提供对EJB Container的支持，但对于商业软件来说，出于产
  品质量和售后服务等因素考虑，商业产品WebLogic或者WebSphere依然是最佳选择。这跟当年
• 欧洲崇尚重装骑兵相似，都免不了要付出高昂的代价。  说到重装骑兵列装和部署的复杂和迟缓，使用EJB开发的企业级应用也存在同样的问题。使用
  EJB使得应用程序的部署和测试都更加困难，复杂的类加载机制、复杂的部署描述符、过长的
  开发部署周期等，无疑都增加了开发EJB应用程序的难度。 
• 重装骑兵需要合适的战机才能发挥其最大作用，EJB也是如此。只有在分布式的场景中，EJB
  才会带给我们最大的益处。但是，当大家在崇拜EJB的狂热氛围之下，不分场景地滥用它时，
  后果自然可想而知了。要么是开发过程缓慢，无法如期交付；要么就是程序交付后性能极差， 很难满足客户需求

当人们意识到大部分J2EE应用开发初期甚至整 个生命周期内都不需要牵扯到分布式架构时，J2EE平台上对应EJB而生的“轻骑兵”自然也该千呼万唤 始出来了——倡导轻量级应用解决方案的Spring，就承担了这一历史角色！
Spring倡导一切从实际出发，以实用的态度来选择适合当前开发场景的解决方案。如果不需要用到
分布式架构，那就没有必要使用EJB之类的“牛刀”。而大多数的J2EE应用也确实不需要在开发初期或 者整个生命周期内引入任何分布式架构。这个时候，采用敏捷、轻量级的开发方案可以收到更好的效果。 Spring所倡导的J2EE轻量级应用解决方案顺应天时，自然得以快速崛起……

spring框架

整个Spring框架构建在Core核心模块之上，它是整个框架的基础。在该模块中，Spring为我们提供了一个IoC容器（IoC Container）实现，用于帮助我们以依赖注入的方式管理对象之间的依赖关系。

AOP模块提供了一个轻便但功能强大的AOP框架，让我们可以以AOP的形式增强各POJO的能力，进而补足OOP/OOSD之缺憾。Spring的AOP 框架符合AOP Alliance规范，采用Proxy模式构建，与IoC容器相结合，可以充分显示出Spring AOP的 强大威力。

Spring框架在Core核心模块和AOP模块的基础上，为我们提供了完备的数据访问和事务管理的抽象和集成服务。在数据访问支持方面，Spring对JDBC API的最佳实践极大地简化了该API 的使用。除此之外，Spring框架为各种当前业界流行的ORM产品，比如Hibernate、iBATIS、Toplink、 JPA等提供了形式统一的集成支持。Spring框架中的事务管理抽象层是Spring AOP的最佳实践，它直接 构建在Spring AOP的基础之上，为我们提供了编程式事务管理和声明式事务管理的完备支持。这些服 务极大地简化了日常应用开发过程中的数据访问和事务管理工作。

为了简化各种Java EE服务（像JNDI、JMS以及JavaMail等）的使用，Spring框架为我们提供了针对这些Java EE服务的集成服务。在Spring的帮助下，这些Java EE服务现在都变得不再烦琐难用。

Spring框架提供了一套自己的Web MVC框架，也就是springMVC，这也是一块需要深入研究的内容。