[No0000170]Spring Boot慢速入门

Spring的实例化Bean有三种方式：

 使用类构造器直接实例化

 使用静态工厂的方法实例化

 使用实例工厂方法实例化

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:context="http://www.springframework.org/schema/context"
        xmlns:tx="http://www.springframework.org/schema/tx"
        xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
                http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
               http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">
       <!-- 使用类构造器直接实例化 -->
        <bean id="userBean1" class="com.szy.spring.implbean.UserBean" />
        <!-- 使用静态工厂的方法实例化 -->
        <bean id="userBean2" class="com.szy.spring.factory.BeanFactory" factory-method="UserBeanService" />
        <!-- 使用实例工厂方法实例化 -->
        <bean id="factory" class="com.szy.spring.factory.BeanFactory" />
        <bean id="userBean3" factory-bean="factory" factory-method="getUserBeanService" />
</beans>  

package com.szy.spring.factory;  

import com.szy.spring.implbean.UserBean;
import com.szy.spring.interfacebean.PersonBean;  

public class BeanFactory
{
    //使用静态工厂的方法实例化使用
    public static PersonBean UserBeanService()
    {
        return new UserBean();
    }  

    public PersonBean getUserBeanService()
    {
        return new UserBean();
    }
}  

Spring的核心机制是依赖注入。依赖注入让bean与bean之间以配置文件组织在一起，而不是以硬编码的方式耦合在一起。依赖注入(Dependency Injection)和控制反转(Inversion of Control)是同一个概念。具体含义是:当某个角色(可能是一个Java实例，调用者)需要另一个角色(另一个Java实例，被调用者)的协助时，在传统的程序设计过程中，通常由调用者来创建被调用者的实例。但在Spring里，创建被调用者的工作不再由调用者来完成，因此称为控制反转;创建被调用者实例的工作通常由Spring容器来完成，然后注入调用者，因此也称为依赖注入。管是依赖注入，还是控制反转，都说明Spring采用动态、灵活的方式来管理各种对象。对象与对象之间的具体实现互相透明。

Spring中属性注入的方式有三种：

使用属性setter方法注入

使用构造器注入

使用注解方式注入

Spring2.5为我们引入了组件自动扫描机制，它可以在类路径下寻找标记了@Component、@Service、@Controller、@Repository注解的类，并把这些类纳入到spring容器中管理，它的作用和在xml中使用bean节点配置组件一样。

• @Service用于标注业务层的组件

• @Controller用于标注控制层组件（如struts中的action）

• @Repository用于标注数据访问组件，即DAO组件

• 而@Component泛指组件，当组件不好归类的时候，我们可以使用这个注解进行标注。但是在目前的spring版本中，这几个注解的作用是一样的，但是在以后可能会进行区分。

https://blog.csdn.net/jsyxcjw/article/details/46490167

使用快捷键移动分割线

可以使用alt+1把鼠标焦点定位到project视图里，然后直接使用ctrl+shift+左右箭头来移动分割线。

不要动不动就使用IDEA的重构功能

如果只是想批量修改某个文本，大可不必使用到重构的功能。 首先是使用ctrl+w选中rabbitTemplate这个文本,然后依次使用5次alt+j快捷键，逐个选中，这样五个文本就都被选中并且高亮起来了，这个时候就可以直接批量修改了。

去掉导航栏

使用alt+v，然后去掉Navigation bar即可。去掉这个导航栏后，如果你偶尔还是要用的，直接用alt+home就可以临时把导航栏显示出来。

把鼠标定位到project视图里

可以先使用alt+F1，弹出Select in视图，然后选择Project View中的Project，回车，就可以立刻定位到类的位置了。

http://blog.didispace.com/intellij-idea-some-features-sam-1/
http://blog.didispace.com/IntelliJ-IDEA-2018-1%E6%AD%A3%E5%BC%8F%E5%8F%91%E5%B8%83%EF%BC%81%E4%BB%80%E4%B9%88%EF%BC%9F%E8%BF%98%E8%83%BD%E8%BF%99%E4%B9%88%E7%8E%A9%EF%BC%9F/

Spring 2.5 在 @Repository 的基础上增加了功能类似的额外三个注解：@Component、@Service、@Constroller，它们分别用于软件系统的不同层次：

• @Component 是一个泛化的概念，仅仅表示一个组件 (Bean) ，可以作用在任何层次。
• @Service 通常作用在业务层，但是目前该功能与 @Component 相同。
• @Constroller 通常作用在控制层，但是目前该功能与 @Component 相同。

通过在类上使用 @Repository、@Component、@Service 和 @Constroller 注解，Spring 会自动创建相应的 BeanDefinition 对象，并注册到 ApplicationContext 中。这些类就成了 Spring 受管组件。这三个注解除了作用于不同软件层次的类，其使用方式与 @Repository 是完全相同的。

另外，除了上面的四个注解外，用户可以创建自定义的注解，然后在注解上标注 @Component，那么，该自定义注解便具有了与所 @Component 相同的功能。不过这个功能并不常用。

使用 @Autowired 注解进行装配，只能是根据类型进行匹配。

当容器中存在多个 Bean 的类型与需要注入的相同时，注入将不能执行，我们可以给 @Autowired 增加一个候选值，做法是在 @Autowired 后面增加一个 @Qualifier 标注，提供一个 String 类型的值作为候选的 Bean 的名字。

https://www.ibm.com/developerworks/cn/opensource/os-cn-spring-iocannt/index.html

理解本真的REST架构风格

REST所继承的架构风格约束

REST架构风格最重要的架构约束有6个：

• 客户-服务器（Client-Server）通信只能由客户端单方面发起，表现为请求-响应的形式。

• 无状态（Stateless）通信的会话状态（Session State）应该全部由客户端负责维护。

• 缓存（Cache）响应内容可以在通信链的某处被缓存，以改善网络效率。

• 统一接口（Uniform Interface）通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。

• 分层系统（Layered System）通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。

• 按需代码（Code-On-Demand，可选）支持通过下载并执行一些代码（例如Java Applet、Flash或JavaScript），对客户端的功能进行扩展。

REST架构风格
而HTTP/1.1协议作为一种REST架构风格的架构实例，其架构如下图所示：

一个基于REST的架构的过程视图
用户代理处在三个并行交互（a、b和c）的中间。用户代理的客户端连接器缓存无法满足请求，因此它根据每个资源标识符的属性和客户端连接器的配置，将每个请求路由到资源的来源。请求（a）被发送到一个本地代理，代理随后访问一个通过DNS查找发现的缓存网关，该网关将这个请求转发到一个能够满足该请求的来源服务器，服务器的内部资源由一个封装过的对象请求代理（object request broker）架构来定义。请求（b）直接发送到一个来源服务器，它能够通过自己的缓存来满足这个请求。请求（c）被发送到一个代理，它能够直接访问WAIS（一种与Web架构分离的信息服务），并将WAIS的响应翻译为一种通用的连接器接口能够识别的格式。每一个组件只知道与它们自己的客户端或服务器连接器的交互；整个过程拓扑是我们的视图的产物。

REST详解

互联网环境与企业内网环境有非常大的差别，最主要的差别是两个方面：

• 可伸缩性需求无法控制：并发访问量可能会暴涨，也可能会暴跌。

• 安全性需求无法控制：无法控制客户端发来的请求的格式，很可能会是恶意的请求。

REST是所有Web应用都应该遵守的架构设计指导原则。当然，REST并不是法律，违反了REST的指导原则，仍然能够实现应用的功能。但是违反了REST的指导原则，会付出很多代价，特别是对于大流量的网站而言。

要深入理解REST，需要理解REST的五个关键词：

1. 资源（Resource）
2. 资源的表述（Representation）
3. 状态转移（State Transfer）
4. 统一接口（Uniform Interface）
5. 超文本驱动（Hypertext Driven）

什么是资源？

资源是一种看待服务器的方式，即，将服务器看作是由很多离散的资源组成。每个资源是服务器上一个可命名的抽象概念。因为资源是一个抽象的概念，所以它不仅仅能代表服务器文件系统中的一个文件、数据库中的一张表等等具体的东西，可以将资源设计的要多抽象有多抽象，只要想象力允许而且客户端应用开发者能够理解。与面向对象设计类似，资源是以名词为核心来组织的，首先关注的是名词。一个资源可以由一个或多个URI来标识。URI既是资源的名称，也是资源在Web上的地址。对某个资源感兴趣的客户端应用，可以通过资源的URI与其进行交互。

什么是资源的表述？

资源的表述是一段对于资源在某个特定时刻的状态的描述。可以在客户端-服务器端之间转移（交换）。资源的表述可以有多种格式，例如HTML/XML/JSON/纯文本/图片/视频/音频等等。资源的表述格式可以通过协商机制来确定。请求-响应方向的表述通常使用不同的格式。

什么是状态转移？

状态转移（state transfer）与状态机中的状态迁移（state transition）的含义是不同的。状态转移说的是：在客户端和服务器端之间转移（transfer）代表资源状态的表述。通过转移和操作资源的表述，来间接实现操作资源的目的。

什么是统一接口？

REST要求，必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。以HTTP/1.1协议为例，HTTP/1.1协议定义了一个操作资源的统一接口，主要包括以下内容：

• 7个HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS

• HTTP头信息（可自定义）

• HTTP响应状态代码（可自定义）

• 一套标准的内容协商机制

• 一套标准的缓存机制

• 一套标准的客户端身份认证机制

REST还要求，对于资源执行的操作，其操作语义必须由HTTP消息体之前的部分完全表达，不能将操作语义封装在HTTP消息体内部。这样做是为了提高交互的可见性，以便于通信链的中间组件实现缓存、安全审计等等功能。

什么是超文本驱动？

“超文本驱动”又名“将超媒体作为应用状态的引擎”（Hypermedia As The Engine Of Application State，来自Fielding博士论文中的一句话，缩写为HATEOAS）。将Web应用看作是一个由很多状态（应用状态）组成的有限状态机。资源之间通过超链接相互关联，超链接既代表资源之间的关系，也代表可执行的状态迁移。在超媒体之中不仅仅包含数据，还包含了状态迁移的语义。以超媒体作为引擎，驱动Web应用的状态迁移。通过超媒体暴露出服务器所提供的资源，服务器提供了哪些资源是在运行时通过解析超媒体发现的，而不是事先定义的。从面向服务的角度看，超媒体定义了服务器所提供服务的协议。客户端应该依赖的是超媒体的状态迁移语义，而不应该对于是否存在某个URI或URI的某种特殊构造方式作出假设。一切都有可能变化，只有超媒体的状态迁移语义能够长期保持稳定。

一旦读者理解了上述REST的五个关键词，就很容易理解REST风格的架构所具有的6个的主要特征：

• 面向资源（Resource Oriented）

• 可寻址（Addressability）

• 连通性（Connectedness）

• 无状态（Statelessness）

• 统一接口（Uniform Interface）

• 超文本驱动（Hypertext Driven）

这6个特征是REST架构设计优秀程度的判断标准。其中，面向资源是REST最明显的特征，即，REST架构设计是以资源抽象为核心展开的。可寻址说的是：每一个资源在Web之上都有自己的地址。连通性说的是：应该尽量避免设计孤立的资源，除了设计资源本身，还需要设计资源之间的关联关系，并且通过超链接将资源关联起来。无状态、统一接口是REST的两种架构约束，超文本驱动是REST的一个关键词，在前面都已经解释过，就不再赘述了。

从架构风格的抽象高度来看，常见的分布式应用架构风格有三种：

• 分布式对象（Distributed Objects，简称DO）架构实例有CORBA/RMI/EJB/DCOM/.NET Remoting等等

• 远程过程调用（Remote Procedure Call，简称RPC）架构实例有SOAP/XML-RPC/Hessian/Flash AMF/DWR等等

• 表述性状态转移（Representational State Transfer，简称REST）架构实例有HTTP/WebDAV

DO和RPC这两种架构风格在企业应用中非常普遍，而REST则是Web应用的架构风格，它们之间有非常大的差别。

REST与DO的差别在于：

• REST支持抽象（即建模）的工具是资源，DO支持抽象的工具是对象。在不同的编程语言中，对象的定义有很大差别，所以DO风格的架构通常都是与某种编程语言绑定的。跨语言交互即使能实现，实现起来也会非常复杂。而REST中的资源，则完全中立于开发平台和编程语言，可以使用任何编程语言来实现。

• DO中没有统一接口的概念。不同的API，接口设计风格可以完全不同。DO也不支持操作语义对于中间组件的可见性。

• DO中没有使用超文本，响应的内容中只包含对象本身。REST使用了超文本，可以实现更大粒度的交互，交互的效率比DO更高。

• REST支持数据流和管道，DO不支持数据流和管道。

• DO风格通常会带来客户端与服务器端的紧耦合。在三种架构风格之中，DO风格的耦合度是最大的，而REST的风格耦合度是最小的。REST松耦合的源泉来自于统一接口+超文本驱动。

REST与RPC的差别在于：

• REST支持抽象的工具是资源，RPC支持抽象的工具是过程。REST风格的架构建模是以名词为核心的，RPC风格的架构建模是以动词为核心的。简单类比一下，REST是面向对象编程，RPC则是面向过程编程。

• RPC中没有统一接口的概念。不同的API，接口设计风格可以完全不同。RPC也不支持操作语义对于中间组件的可见性。

• RPC中没有使用超文本，响应的内容中只包含消息本身。REST使用了超文本，可以实现更大粒度的交互，交互的效率比RPC更高。

• REST支持数据流和管道，RPC不支持数据流和管道。

• 因为使用了平台中立的消息，RPC风格的耦合度比DO风格要小一些，但是RPC风格也常常会带来客户端与服务器端的紧耦合。支持统一接口+超文本驱动的REST风格，可以达到最小的耦合度。

比较了三种架构风格之间的差别之后，从面向实用的角度来看，REST架构风格可以为Web开发者带来三方面的利益：

• 简单性

采用REST架构风格，对于开发、测试、运维人员来说，都会更简单。可以充分利用大量HTTP服务器端和客户端开发库、Web功能测试/性能测试工具、HTTP缓存、HTTP代理服务器、防火墙。这些开发库和基础设施早已成为了日常用品，不需要什么火箭科技（例如神奇昂贵的应用服务器、中间件）就能解决大多数可伸缩性方面的问题。

• 可伸缩性

充分利用好通信链各个位置的HTTP缓存组件，可以带来更好的可伸缩性。其实很多时候，在Web前端做性能优化，产生的效果不亚于仅仅在服务器端做性能优化，但是HTTP协议层面的缓存常常被一些资深的架构师完全忽略掉。

• 松耦合

统一接口+超文本驱动，带来了最大限度的松耦合。允许服务器端和客户端程序在很大范围内，相对独立地进化。对于设计面向企业内网的API来说，松耦合并不是一个很重要的设计关注点。但是对于设计面向互联网的API来说，松耦合变成了一个必选项，不仅在设计时应该关注，而且应该放在最优先位置。

有的读者可能会问：“你说了这么多，REST难道就没有任何缺点了吗？”当然不是，正如Fielding在博士论文中阐述的那样，评价一种软件架构的优劣，不能脱离开软件的具体运行环境。永远不存在适用于任何运行环境的、包治百病的银弹式架构。笔者在前面强调过REST是一种为运行在互联网环境中的Web应用量身定制的架构风格。REST在互联网这个运行环境之中已经占据了统治地位，然而，在企业内网运行环境之中，REST还会面临DO、RPC的巨大挑战。特别是一些对实时性要求很高的应用，REST的表现不如DO和RPC。所以需要针对具体的运行环境来具体问题具体分析。但是，REST可以带来的上述三方面的利益即使在开发企业应用时，仍然是非常有价值的。所以REST在企业应用开发，特别是在SOA架构的开发中，已经得到了越来越大的重视。本专栏将有一篇文章专门介绍REST在企业级应用中与SOA的结合。

到了这里，“REST究竟是什么”这个问题笔者就解答完了。本文开头那些说法是否正确，笔者还是笑而不语，读者此时应该已经有了自己的判断。在接下来的REST系列文章中，我将会为读者澄清一些关于HTTP协议和REST的常见误解。

http://www.infoq.com/cn/articles/understanding-restful-style