《Spring实战》第一章 Spring之旅 整理及感想

写在前面的话：
因为自己想转java后端开发嘛，所以一直在学习相关知识，但其实学习java基础是比较简单的，当学习到框架的时候就很烦：

• 不懂为啥要用框架
• 各个框架都是用来干啥的啊
• 什么Spring、SpringMVC、MyBatis、Structs、hibernate等等都有啥区别
  。。。
  等等一系列的问题，导致学框架就很费劲。我先是照着视频学，再是百度看博客之类的，但还是一知半解，摸不到门槛，正好某东图书优惠，买了本《Spring实战》。得，系统地学总没错吧。
  【当然有这个觉悟还是要归功于去某东面试的时候，与二面的技术负责人的交谈（实是收获颇多）。】

为了利人利己吧，我决定把看书的感悟都记录下来，有不当之处还请各位指正哈
（有不懂的名词建议百度一下）

---

好了，言归正传，开始

《Spring实战》第一章 Spring之旅

首先，“Spring是为了解决企业级应用开发的复杂性而创建的，使用Spring可以实现之前只有EJB才能完成的事情“。
其实就是开发企业级的大应用的时候，人们发现程序太复杂了，整个程序的功能、对象等都交织在一起（想象一下，就光一个会员系统，你得牵涉多少东西进去：优惠度、权益、订单等等），不管是可读性、可维护性、可测试性等等，都相当差，那就想办法让这个大程序简单点。
那Spring是怎么让程序简单起来呢，有四点：

基于POJO的轻量级和最小侵入性编程；

意思就是在使用Spring的过程中，Spring不会强迫开发人员去实现Spring规范的接口或者是继承Spring规范的类，就尽量让程序保持POJO，没有被SPring弄乱。

通过依赖注入和面向接口编程实现松耦合；

其实是Spring充当代理的角色，像书中的例子，一个骑士要来执行任务，那不能骑士执行一个任务就创建一个相应地类吧？屠龙类、拯救公主类？其实那么热血，那得创建多少个任务类啊。所以就有了面向接口编程的方式：勇敢的骑士要执行任务，那好，骑士做好准备，碰到啥可以直接做的任务就执行啥任务。就像赏金猎人似的，我说我缉拿大盗，不管是偷盗了啥的，都可以来缉拿，传过来的只要是大盗thief（）就行，至于是偷钱还是偷文物，只要是大盗（实现了大盗thief()这个接口）就行。这种的就是DI（依赖注入），就是把这种对象与对象之间的关系自动交给目标对象（也就是骑士、赏金猎人），不用目标对象是获取依赖（也就是不用自己去识别这是不是大盗之类的）。

基于切面和惯例进行申明式编程；

其实就是把业务逻辑代码与关注点（类似系统服务这样，系统到处都得实现，但又与具体的业务逻辑代码没太大关系，譬如日志）代码分离开来。书中举的例子是，有那种吟游诗人专门去记载骑士的事迹，说骑士在完成任务之前都有啥，完成任务的时候都是怎么干的，最后可能还得感慨一番啊啥的。但对于整个过程而言，最重要当然还是骑士完成任务的部分，但作为骑士，总不能每次去做任务前都说，哎，来，快来记录，我要准备完成任务了。明显骑士的重任是拯救公主啥的，也没那些闲工夫去做这个，那怎么办呢，那就得吟游诗人自己想办法了啊，得关注着自己需要歌颂的骑士，当骑士在完成任务前，自己应该写点什么，在骑士完成任务的途中，自己应该怎么纪实，后续又是怎么进行开展。那骑士呢，骑士当然啥都不管啊，就拯救公主就行了。在程序中，也就是将吟游诗人抽象成一个切面（也就是个壳子一样），把骑士包圆起来，也就是跟监听似的，你一动我就知道，然后我就开始行动了。

通过切面和模板减少样式代码。

所谓的样板式代码其实就是差不多一个套路的一堆代码，就像jdbc，用java语言连接数据库，每次都需要建立连接、创建语句对象、执行语句、捕捉SQLException异常、关闭连接...等等。差不多除了语句不一样，其他都一样，在正常的系统中，会经常操作数据库，那每次操作数据库都这么多繁琐的东西，写起来既浪费时间又没啥用，还影响程序可读性。为了让这些重复性的代码不用“傻瓜式”的到处写，使用Spring的JdbcTemplate就可以简化很多。

后面再写了bean的生命周期，这个得死记的东西，没啥都巴拉的了。
还有Spring的强大，给很多java领域提高Spring编程模型。当然我也学不了那么多，略过略过。

---

学习了第一章吧，其实主要还是对Spring有个大体的了解，知道为啥用它（因为用了程序简单了,也就是所谓让代码松散耦合），它的一些基本点（DI（依赖注入）、AOP（面向切面编程））.
有个隐形就行，接下来几章才是细说，加油！