更简单的存和取bean

注解

注解：声明和表示这个类或方法有某个能力。servlet的Web注解；实现路由的注册。
逻辑的实现：编译器自动生成代码；直接给你加上代码。（注解替换对应的代码）

储存Bean：
（之前的储存的方法一点麻烦；比直接new对象还要麻烦；存一个就要去配置文件添加bean标签。）
使用注解储存：存对象在spring中有两种注解类型；加了这些注解的类；就会自动的帮我存。

类注解

5大类注解@Controller、@Service、@Repository、@Component、@Configurtion

Controller；控制器和用户打交道；这个类将是和用户直接接触；校验工作。检查前端的传参正不正确和合不合规。跟高铁安检一样。（比如sql注入；或者黑客爬虫；访问频率特别高；发现就给他拉黑名单）

service：服务层；实现这个功能需要调用哪些接口；它会帮你调用。但是底下执行不是在这里操作数据库

Repository：持久层；操作数据库；执行者。（DAO层就是数据交互层；持久层是它的一种实现。可以理解一个东西）

Component：组件；以上都不适合放上面的东西；比如加密；就放在这里给spring托管。

Configurtion：配置项；项目一些配置配置

方法注解

方法注解@Bean

类注解存bean

准备工作：

为了极致的性能：告诉它；哪个目录需要扫描；不可能全部的类都去扫描；拉低效率。不配置这个东西；哪怕你加了注解；但是依然也不会工作的。在这个路径下；如果有五大注解的就添加到spring。（路径外是没效果的）

使用：

取bean；目前还是使用之前的方法验证。
但是有个问题；我之前是通过id来存取的；现在怎么取呢、（使用注解没有id ）。如果用原类名会报错；（约定：首字母大小换小写就能取。特殊情况第二个字母也是大写SController；这种使用原类名）

目前取还是原来的方法去取：成功取到这个对象并执行方法

这里使用其它的注解也是同样能达到效果；但是不规范；开发得要符合标准分层；因为不同注解是在不同的层次上工作。

1：那么使用了这个component-san；还能不能再使用前面学习的不简单bean的储存（就是在配置文件是复杂的配置）。当然是可以的；就是说；我大部分要注入的需求在这个component-san路径下；但是我有极小部分需要注入；而配置扫描这个路径有点降低效率；所以bean能补充这种情况。

2：如果五大类注解你加在这个路径之外；是不能读取的；为了性能只会扫描配置的包里。
3：在配置的这个包底下；不加5大类注解；也是不能读取到和添加到spring里；
4：在上述配置的路径底下再建一个包；在这个新建的包底下加的注解；也可以成功储存进去。
在这种情况下的；父包和子包有相同名字的类呢；能不能顺利的存和取。不能的；储存的时候就报错了；注解关于这个类有两个。（要么改类名；要么起别名；注解有个value属性；避免这种情况；）

五大注解关系：
其它的全是基于compoent实现。相当于一个父类；四个子类。子是父的一个扩展。产生这个多注解是为了分层下的工作。
javaEE标准分层：至少要包含三层；控制层；服务层，数据交互层（叫数据持久层比较多；经常一张表对应一个）一般公司会在三层的基础上扩展和细分。注解能很好的标识；一看这个注解就知道是哪层的。

bean命名规则：两套；默认情况类名首字母小写；如果默认情况不行就使用原类名；那就一定可以。
Ctrl+shift+R全局搜索；搜索beanname；优秀的代码肯定是有能望文生义的名字；试一试能不能找到结果。源自jdk的一种命名规则。

方法注解存bean

@Bean是方法注解；不能加在类上；加在方法上；要求当前的方法必须有返回值；得搭配类注解一起用。（spring规定；还是为了效率、性能；因为使用Bean注解还是少数的；我不可能所有的方法都要将这个返回值储存进去；所以就加个注解；只扫描这个注解里的。）
命名规则
默认情况下储存的名字是方法名。取的时候有点尴尬；有时候方法名作为对象名。
设置名字：Bean注解的name属性；重命名的效果。但是这个命名可以是数组（可以起很多个名字）；name和value属性都是同样的重命名。所有的名字都可以取。这时候原来的方法名也就无法进行获取对象。

体验一下@Bean注解使用：
先凭空产生个对象；用来存；里面生成get和set方法。



如果方法名一样：
两个类里；方法名是一样的；并且我们也不重命名；那这是什么情况呢；相当于覆盖？@order 注解有个value设置；名字的设置；这个值越小；就越先加载。后面的会覆盖前面的。
重载：参数没法注入；我们没法给这个参数传东西。所以这种bean只能是无参的。不行的。

注意：存bean；如果路径是和java下的同级；使用注解的方式注入是不好写配置扫描的路径。

按spring规定的层次去创建这个目录即可；spring：约定大于配置

更简单的获取bean

对象装配；也叫DI；依赖注入。
1：属性注入
加注解从spring得到这个对象；然后给这个变量。不能在static里写；静态的执行是高于这个spring的存对象的；通过注解是得不到bean对象。加载顺序高于spring。后面spring boot和spring MVC是可以拿；因为是通过tomcat启动的。（所以main方法里的取对象还是这的三板斧）

一个注解就能搞定；非常简洁

它是先去spring读取有没有这个类型的对象；如果只有一个对象就赋值于我们这个变量；我们这个变量的取名尽量是和spring的bean是一样；当然你使用us；aaa；usaaa也是能正常读取到这个对象。如果有多个对象；就会根据这个名字去匹配唯一的对象。

验证：现在已经把这个对象初始化；存到spring去；看看上述能不能取到结果.。怎么验证；main方法又不能使用这种方法取；我们可以把这个App1类存到spring去；然后用三板斧的方法在main取bean；看看这个里面的user对象是否初始化了。（或者我这里使用配置文件bean方式注入这个App1；）

确实使用Autowired获取到结果

优点：简洁
缺点：没法实现final修饰变量的注入。（没法给final修饰的属性赋值）；兼容不好；只适用于IoC容器。
容易违背单一设计原则；一个类只做一件事情。比如过度注入：如果一个类依赖过多的其他类，并且通过Autowired注入方式将这些依赖注入进来，可能会使类的职责不明确，难以理解和维护。

2：setter注入；set方法右键生成就好了

这个注解取的spring的bean会给参数赋值；
优点：
始终传的是单一的对象；符合单一设计原则；每个方法只传递一个对象。
缺点：没法实现final修饰变量的注入。
注入的对象可能会被改变；比如注入完；代码在下方又调用这个setter方法；并传一个参数；就把这个对象改变了。我可以任意的位置调用这个方法；修改这个传入的参数。

3：构造方法注入；官方推荐
只有一个构造方法；允许你不加@Autowired都行

优点：
1：可以实现final修饰变量的注入。（final修饰对象两个条件之一；要么直接赋值；要么在构造方法中赋值）
2：注入的对象不会被改变（构造方法只会执行一次）
3：构造方法注入可以保证注入对象被完全初始化；由于依赖对象是在构造方法中进行传递的，所以在构造方法执行完毕之前。
4：通透性更好；通透性指的是将依赖对象注入到类中的程度有多高，即依赖注入是否能够完全满足类对依赖对象的需求。构造方法注入有良好的可测试性、灵活性和可替代性。

另一种注入关键字：Resource
这个是jdk；上面是spring的；就把刚才上面的注解换成这个；效果是一样的。但是这个注解在构造方法注入是不能用的。
区别：
来自的地方不同：jdk；spring。
注入的支持上：Resource构造方法注入不支持
Resource支持更多参数设置：正常使用两个是没有区别的；特殊场景；autowired是有短板了；可以用Resource弥补。

Spring的查bean方式

Spring在找bean有两种方式：而上述两个注解都会使用到；但是他们的顺序是不同
1：根据类型查找
2：根据名称查找
@Autowired会先根据类型查找；然后根据名称查找。如果类型只有这一个bean；那么就不执行后面的。如果有多个bean就执行后面的名称查找。如果名称查找；还找不到唯一的bean；那么就报错了。
比如：你存的是user1、user2.你要找user。

@Resource 先根据名称查找；然后根据类型去查找；可以设置name属性；而Autowired没有name属性设置。使用Qualifier也能达到筛选效果。