《Spring实战（第4版）》

第1章 Spring之旅

1.1 简化Java开发

• Spring是为了解决企业级应用开发的复杂性而创建的，使用Spring可以让简单的 JavaBean实现之前只有EJB才能完成的事情。但Spring不仅仅局限于服务器端开发，任何Java应用都能在简单性、可测试性和松耦合等方面从 Spring中获益。
• Spring竭力避免因自身的API而弄乱你的应用代码。Spring不会强迫你实现Spring规范的接口或继承Spring规范的类，相反，在基于Spring构建 的应用中，它的类通常没有任何痕迹表明你使用了Spring。最坏的场景是，一个类或许会使用Spring注解，但它依旧是POJO。
• 依赖注入，DI-Dependency Injecttion
  按照传统的做法，每个对象负责管理与自己相互协作的对象（即它所依赖的对象）的引用，这将会导致高度耦合和难以测试的代码。
  依赖注入会将所依赖的关系自动交给目标对象，而不是让对象自己去获取依赖，如下图所示：
  
• 面向切面编程，AOP-Aspect-Oriented Programming
  DI能够让相互协作的软件组件保持松散耦合，而面向切面编程(aspect-oriented programming，AOP)允许你把遍布应用各处的功能分离出来
  形成可重用的组件。
• 使用模板消除样板式代码
  样板式的代码(boilerplate code)，通常为了实现通用的和简单的任务，你不得不一遍遍地重复编写这样的代码。

容纳你的Bean

• 在基于Spring的应用中，你的应用对象生存于Spring容器(container)中。如下图所示，Spring容 器负责创建对象，装配它们，配置它们并管理它们的整个生命周期，从生存到死亡(在这里，可能 就是new到finalize())。
  
• bean的生命周期

第2章 装配Bean

结论

• 推荐使用类型安全并且比XML更强大的JavaConfig
• 尽肯能使用自动化配置，显示配置越少越好

2.2 自动化装配bean

• @Component、@Named（Java依赖注入规范，Java Dependency Injection）
  Spring支持将@Named作为@Component注解的替代方案。两者之间有一些细微的差异，但是在大多数场景中，它们是可以互相替换的。话虽如此，我更加强烈地喜欢@Component注解，而对于@Named……怎么说呢，我感觉它的名字起得很不好。它并没有像@Component那样 清楚地表明它是做什么的。因此在本书及其示例代码中，我不会再使用@Named。
• @Autowired、@Inject（Java依赖注入规范，Java Dependency Injection）
  @Inject注解来源于Java依赖注入规范，该规范同时还为我们定义了@Named注解。在自动装配中，Spring同时支 持@Inject和@Autowired。尽管@Inject和@Autowired之间有着一些细微的差别，但是在大多数场景下，它们都是可以互相替换的。
  在@Inject和@Autowired中，我没有特别强烈的偏向性。实际上，在有的项目中，我会发现我同时使用了这两个注解。不过在本书的样例 中，我会一直使用@Autowired，而你可以根据自己的情况，选择其中的任意一个。
• System Rules
  在测试代码中使用System.out.println()是稍微有点棘手的事情。因此，该样例中使用了StandardOutputStreamLog，这是来源于 System Rules库(http://stefanbirkner.github.io/system-rules/index.html)的一个JUnit规则，该规则能够基于控制台的输出编写断言。在这里，我 们断言SgtPeppers.play()方法的输出被发送到了控制台上。

2.3 通过Java代码装配bean

• @Configuration
• @ComponentScan
  
  • 如果不设置任何属性，按照默认规则，它会以配置类所在的包作为基础包（base package）来扫描组件。
  • basePackageClasses属性
    设置的数组中包含了类，这些类所在的包将作为组件扫描的基础包。
• @Bean
  默认情况下，bean的ID与带有@Bean注解的方法名是一样的，可以通过name属性指定一个不同的名字。

@Bean(name="lonelyHeartsClubBand")
public CompactDisc sgtPeppers() {
    return new SgtPeppers();
}

Spring 将会拦截所有对标有@Bean注解方法的调用，并确保直接返回该方法所创建的bean，而不是每次都对其进行实际的调用。
方法调用引入bean的方式有点令人困惑，通过参数的方式引入bean，Spring会自动装配bean到配置方法中，这种方式的优点：不要求被装入bean声明到同一个配置类中，甚至不要求必须在JavaConfig中声明，它可以通过组件扫描功能或者通过XML来进行配置。

2.4 通过XML装配bean

• 如果没有明确给定ID，将会根据全限定类名来进行命名。在本例中，bean的ID将会是”soundsystem.SgtPeppers#0”。其 中，”#0”是一个计数的形式，用来区分相同类型的其他bean。
• 为了减少XML中繁琐的配置，只对那些需要按名字引用的bean（比如，你需要将对它的引用注入到另外一个bean中）进行明确地命名。
• c-命名空间
  与功能类似，支持按参数索引或参数名注入，缺点：不支持将集合装配到构造器参数中。
• p-命名空间
  与功能类似，缺点：不支持将集合装配到构造器参数中
• Spring util-命名空间
  其中的一些功能可简化bean的配置，如下所示：

元素	描述
	引用某个类型的public static域，并将其暴露为bean
	创建一个java.util.List类型的bean，其中包含值或引用
	创建一个java.util.Map类型的bean，其中包含值或引用
	创建一个java.util.Properties类型的bean
	引用一个bean的属性(或内嵌属性)，并将其暴露为bean
	创建一个java.util.Set类型的bean，其中包含值或引用

2.5 导入和混合配置

关于混合配置，第一件需要了解的事情就是在自动装配时，它并不在意要装配的bean来自哪里。自动装配的时候会考虑到Spring容器中所有的 bean，不管它是在JavaConfig或XML中声明的还是通过组件扫描获取到的。

• 在JavaConfig中引用JavaConfig配置
  @Import(CDConfig.class)
• 在JavaConfig中引用XML配置
  @ImportResource(“classpath:cd-config.xml”)
• 在XML配置中引用JavaConfig
  将JavaConfig导入到XML配置中，