江苏龙网

  1. 主页 > 生活百科 > >

扒一扒Spring家族的前世今生

spring

在Spring框架没有开发出来时 ， JAVA EE是以Sun公司（已经被Oracle公司收购 ， 不复存在 ， 但为了纪念其对Java发展进程的巨大影响力 ， 全书还是保留其名称 ， 以表致敬之意）所制定的EJB（Enterprise Java Bean）作为标准的 。
在“遥远”的EJB年代 ， 开发一个EJB需要大量的接口和配置文件 ， 直至EJB 2.0的年代 ， 开发一个EJB还需要配置两个文件 ， 其结果就是配置的工作量比开发的工作量还要大 。
其次EJB是运行在EJB容器中的 ， 而Sun公司定义的JSP和Servlet却是运行在Web容器中的 ， 于是你可以想象得到 ， 你需要使用Web容器去调用EJB容器的服务 。
这就意味着存在以下的弊端：需要增加调用的配置文件才能让Web容器调用EJB容器；与此同时需要开发两个容器 ， 非常多的配置内容和烦琐的规范导致开发效率十分低下 ， 这非常让当时的开发者诟病；对于Web容器调用EJB容器的服务这种模式 ， 注定了需要通过网络传递 ， 造成性能不佳；对于测试人员还需要了解许多EJB烦琐的细节 ， 才能进行配置和测试 ， 这样测试也难以进行 。
就在大家诟病EJB的时候 ， 2002年澳大利亚工程师Rod Johnson（论学历他应该是音乐家 ， 因为他是音乐博士）在其著名的著作Expert One-on-One J2EE Design and Development中提出了Spring的概念 。
然后在2004年由Rod Johnson主导的Spring项目推出了1.0版本 ， 这彻底地改变了Java EE开发的世界 ， 很快人们就抛弃了繁重的EJB的标准 ， 迅速地投入到了Spring框架中 ， 于是Spring成为了现实中Java EE开发的标准 。
Spring以强大的控制反转（IoC）来管理各类Java资源 ， 从而降低了各种资源的耦合；并且提供了极低的侵入性 ， 也就是使用Spring框架开发的编码 ， 脱离了Spring API也可以继续使用 。
而Spring的面向切面的编程（AOP）通过动态代理技术 ， 允许我们按照约定进行配置编程 ， 进而增强了Bean的功能 ， 它擦除了大量重复的代码 ， 如数据库编程所需大量的try…catch…finally…语句以及数据库事务控制代码逻辑 ， 使得开发人员能够更加集中精力于业务开发 ， 而非资源功能性的开发 。
Spring还提供许多整合了当时非常流行的框架的模板 ， 如持久层Hibernate的HibernateTemplate模板、iBATIS的SqlMapClientTemplate模板等 ， 极大地融合并简化了当时主流技术的使用 ， 使得其展示了强有力的生命力 ， 并延续至今 。
值得一提的是 ， EJB 3.0的规范也引入了Spring的理念 ， 而且整合了Hibernate框架的思想 ， 但是也未能挽回其颓势 ， 主要原因在于它的规范还是比较死板 ， 而且比较难整合其他开源框架 。其次 ， 它运行在EJB容器之中 ， 使用上还是比较困难 ， 性能也不高 。
注解还是XM
只是在Spring早期的1.x版本中 ， 由于当时的JDK并不能支持注解 ， 因此只能使用XML 。而很快随着JDK升级到JDK5 ， 它加入了注解的新特性 ， 这样注解就被广泛地使用起来 ， 于是Spring的内部也分为了两派 ， 一派是使用XML的赞同派 ， 一派是使用注解的赞同派 。
为了简化开发 ， 在Spring 2.x之后的版本也引入了注解 ， 不过只是少量的注解 ， 如@Component、@Service等 ， 但是功能还不够强大 ， 因此对于Spring的开发 ， 绝大部分的情况下还是以使用XML为主 ， 注解为辅 。
到了Spring 3.0后 ， 引入了更多的注解功能 ， 于是在Spring中产生了这样一个很大的分歧 ， 即是使用注解还是使用XML？对于XML的引入 ， 有些人觉得过于繁复 ， 而对于注解的使用 ， 会使得注解分布得到处都是 ， 难以控制 ， 有时候还需要了解很多框架的内部实现才能准确使用注解开发所需的功能 。
这个时候大家形成了这样的一个不成文的共识 ， 对于业务类使用注解 ， 例如 ， 对于MVC开发 ， 控制器使用@Controller ， 业务层使用@Service ， 持久层使用@Repository；而对于一些公用的Bean ， 例如 ， 对于数据库（如redis）、第三方资源等则使用XML进行配置 ， 直至今时今日这样的配置方式还在企业中广泛地使用着 。


推荐阅读


上一篇：想要快速认识电脑接口，看这篇就够了

下一篇：盘点美国主要的基础软件和工业软件