注解（更简单存bean和取bean）

注解：声明和表示这个类或方法有某个能力。servlet的Web注解；实现路由的注册。
逻辑两种实现方式：
编译器自动生成代码；直接给你加上代码。（注解替换对应的代码）
拦截;事务；先拦截；然后开启事务；让程序执行；如果中途程序执行失败；回滚事务；如果方法执行成功就提交事务。

储存Bean：
（之前的储存的方法一点麻烦；比直接new对象还要麻烦；存一个就要去配置文件添加bean标签。）
使用注解储存：存对象在spring中有两种注解类型；加了这些注解的类；就会自动的帮我存。
1.类注解@controller、@Service、@Repository、@Compooent、@Configurtion
5大注解：
Controller；控制器和用户打交道；这个类将是和用户直接接触；校验工作。检查前端的传参正不正确和合不合规。跟高铁安检一样。（比如sql注入；或者黑客爬虫；访问频率特别高；发现就给他拉黑名单）
service：服务层；实现这个功能需要调用哪些接口；它会帮你调用。但是底下执行不是在这里操作数据库
Repository：持久层；操作数据库；执行者。（DAO层就是数据交互层；持久层是它的一种实现。可以理解一个东西）
Compooent：组件；以上都不适合放上面的东西；比如加密；就放在这里给spring托管。
Configurtion：配置项；项目一些配置配置
2.方法注解@Bean

更简单的存bean（使用类注解）

准备工作：

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

使用：

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

成功取到这个对象并执行方法

这里使用其它的注解也是同样能达到效果；但是不规范；因为不同注解是在不同的层次上工作。

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

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

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

方法注解

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

先凭空产生个对象；用来存；里面生成get和set方法。

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

更简单的获取bean

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

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

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

优点：简洁
缺点：没法实现final修饰变量的注入。（没法给final修饰的属性赋值）；兼容不好；只适用于IoC容器。
写法简单；唯一单一设计原则概率更大。单一；一个类只做一件事情。

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

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

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

优点：
1：可以实现final修饰变量的注入。（final修饰对象两个条件之一；要么直接赋值；要么在构造方法中赋值）
2：注入的对象不会被改变（构造方法只会执行一次）
3：构造方法注入可以保证注入对象被完全初始化
4：通透性更好

这里优缺点的理解不是特别清晰啊。

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