日升时奋斗,日落时自省
目录
1、存储Bean对象
1.1、五大类注解
1.2、添加注解存储Bean对象(Controller)
1.3、Bean的命名规则
1.4、其他类注解演示
1.5、为什么需要五大类注解
1.5.1、JavaEE标准分层
1.5.2、实例分层结构
1.5.3、分层领域规约
2、@Bean方法注解
2.1、配合类注解使用
2.2、重命名问题(同类下)
2.3、重命名问题(不同类下)
3、对象注入
3.1、属性注入
3.2、Setter注入
3.3、构造方法注入
3.4、@Resource注入(搭配)
3.5、@Resource与@Autowired区别
前面博客告诉了问如何创建Spring和使用,但是存储方式还是比较复杂的,如果要使用的多个对象,那不得要多个Bean标签,几时几百个类进行处理(冗余代码太多)
现在有了注解,能够放方便的存储和获取Bean对象,在Spring中想要更简单的存储和获取对象的核心是使用注解
注解是什么??
代码中的特殊标记,这些标记可以在编译、类加载、运行时被读取,从而做相对应的处理。
注解优势:简化代码,降低耦合性,提高执行效率
1、存储Bean对象
这里还是需要Spring配置文件,配置文件(我们在resources文件下创建一个Spring配置文件spring-config.xml)还是上一个博客中提供的
<?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:content="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context https://www.springframework.org/schema/context/spring-context.xsd">
<content:component-scan base-package="com.bit.service"></content:component-scan>
</beans>
这次就不需要删除什么了
来看一下,这里要怎么使用这个spring配置文件
现在问题来了:有那些相关注解会被使用到
1.1、五大类注解
@Controller注解:表示一个处理HTTP请求的控制器对象,控制器,验证用户请求的数据正确性(安全保证系统)
注:如果有人恶意访问(尝试攻击或者测试),就会被拦截下来,接收前端传递的请求,查看前端的信息是否正确
@Service:服务类为其他组件提供了一种复用业务逻辑的方法,能够减少重复代码的编写,提高代码的可维护性(客服中心);重点在于编排和调度具体的执行方法
@Repository:持久层 :持久层是指与数据库有交互的逻辑层方便在Service层中进行调用
@Component:组件(是个工具类)用于标识一个类作为一个可被扫描的组件
@Configuration:配置项:(项目中的一些配置)在Spring容器中作为一个配置类,并且被用来替代XML配置文件
1.2、添加注解存储Bean对象(Controller)
此处是先以Controller注解作为演示的
启动类具体上没有很大的变化,但是参数上有些许变化
1.3、Bean的命名规则
类似id 参数名称是有一套规则的(接下来来解释)
那现在就拿这个规则来试一下开头如果是两个大写字符的类,在规则下,能不能跑起来
这里创建一个类SController来演示
总结bean的name规则:
<1>如果类名前两个字符都是大写字母,那bean的name就不需要改变,就写原类名就可以
<2>如果类名前两个字符只有第一给字符是大写字母,那bean的name只需要将第一个字符小写即可
1.4、其他类注解演示
前面使用了@Controller进行类对象注入Spring,那Service,Repository,Component,Configuration这些注解也是可以的
下面就简单的操作一下其他的类注解
注解的真正用途:其他注解也能实现,并且实现注解还都是Component注解,这样重复出现也不起不到什么作用了,这些类注解主要目的是为了分层的
1.5、为什么需要五大类注解
这里的分层就和开始针对注解的作用,让别的人一看就能看懂你的项目那部分是干什么的
<1>@Controller:表示就是业务逻辑层
<2>@Service:服务层(针对端口等)
<3>@Repository:持久层
<4>@Configuration:配置层
此处拿阿里巴巴的分层结构给友友们解释
1.5.1、JavaEE标准分层
Java标准分层 ,可以分为三层,有的地方将分层分为了四层,这里都会做以解释
JavaEE标出分层至少被分为三层(此处演示三层)
<1>控制层
控制层负责处理用户请求并将请求转发给业务逻辑层,同时还需要对请求参数进行验证和过滤等处理,并将处理结果封装成响应对象返回给客户端
<2>服务层
服务层具有独立性和可重用性,可以被多个控制器共用,提高代码的复用性和可维护性。
<3>数据持久层
控制层负责处理用户请求并将请求转发给业务逻辑层,同时还需要对请求参数进行验证和过滤等处理,并将处理结果封装成响应对象返回给客户端
1.5.2、实例分层结构
这里实例分层结构具体拿阿里巴巴的为例(还是很有权威的)
为什么会有业务逻辑和通用逻辑层,都是逻辑层,出现两个干什么,主要区别在于操作什么数据
通用业务逻辑层:
对第三方平台封装的层,预处理返回结果及转化异常信息;
对 Service 层通用能力的下沉,如缓存方案、中间件通用处理;
与 DAO 层交互,对多个 DAO 的组合复用。
也就是不需要什么操作都要通过Service层
1.5.3、分层领域规约
以下引用部分的区分都是来自于《Java开发手册-嵩山版》
<1> DO( Data Object): 此对象与数据库表结构一一对应,通过 DAO 层向上传输数据源对象。
<2> DTO( Data Transfer Object):数据传输对象, Service 或 Manager 向外传输的对象。
<3> BO( Business Object):业务对象, 可以由 Service 层输出的封装业务逻辑的对象。
<4> Query:数据查询对象,各层接收上层的查询请求。 注意超过 2 个参数的查询封装,禁止使用 Map 类来传输。
<5> VO( View Object):显示层对象,通常是 Web 向模板渲染引擎层传输的对象
给出以上分层是为了类名使用的
我们代码中也是这么分层,基本上是依照这样的分层格式,我门写代码也将这些细致化分为四层也就是四个包
service包,entity包,component包,controller包(分别写什么代码)
(1)service层:是业务逻辑层,包中存放的不是具体业务类,而是一些接口
(2)entity层:放置一个个实体,及其相应的set、get方法。如果想要对数据库进行一些操作的话,就要先写entity层(也有叫做model或者models都是一个东西,只是派系不同而已)
(3)component层:存放一些组件
(4)controller层:只接收数据,然后校验数据,校验合法性和准确性,(比如接收用户信息)
对象命名规范:
<1> 基本对象(对应数据库中的一张表):表名:Userinfo 或者 UserinfoEntity 又或者使用UserinfoDo等
<2> 扩展对象:使用Userinfo / UserinfoOtherVO / Userinfo...VO
2、@Bean方法注解
2.1、配合类注解使用
有类注解使用,针对方法注解顾名思义:注解添加到方法上(直接开始演示)
注:从@Bean方法注解中,如何获取Bean对象,直接写方法名称就行(不用加任何修饰)
2.2、重命名问题(同类下)
涉及到:@Bean对象的参数
如果@Bean方法注解如果重名了需要怎么办(情况特殊,基本不能改的情况下,这里就可以给该方法起一个别名)
这里假设刚刚user1 这个名字已经用不了了,而且因为特殊原因还不能修改的
注:
<1>起了别名以后的方法 ,只能使用别名来获取,不能再使用本名来获取
<2>别名可以起多个
2.3、重命名问题(不同类下)
主要扩展一个 新的注解 : @Order(参数)
如果在不同类下有相同方法名,获取Bean对象的时候,是不会报错,执行代码也是遵循从上到下的(这里稍作演示)
注:@Order(参数) 该注解的参数 越大加载就越滞后,所以可通过该注解针对不同类重命名的
3、对象注入
有以下3种方法
<1> 属性注入
<2> Setter注入
<3> 构造方法注入
下面使用Service类注入到Controller类中
3.1、属性注入
提示:对象注入需要使用到@Autowired注解,所以属性注入也需要
在属性上方加上@Autowired注解
优点:代码简单
缺点:
<1> 不能给final修饰的变量进行注入
<2> 兼容性较差:只适用于IoC容器
<3> 风险:容易违背单一设计原则
3.2、Setter注入
使用一个方法注入 ,叫做Setter注入 给一个注入方法上方加上一个@Autowired注解
启动类没有改变,还是原来的启动类(这里只是不同的注入方式,名没有改变类名)
优点:符合单一变量原则(固定格式避免违背单一变量原则)
缺点:
<1>不能给final修饰的属性进行对象注入
<2>Setter注入的属性容易被改变
其实我感觉这个是可以避免一点点的,让该方法使用private权限修饰,启动类就访问不到了
3.3、构造方法注入
优点:
<1>可以注入一个final修饰的对象
<2>注入对象不会进行改变
<3>构造方法可以确定对象的初始化
<4>通用性很高
这里主要依赖于java的基本语法
<1>final修饰的属性在开始创建时就需要赋值
<2>final修饰的属性如果在开始的时候没有进行赋值,那就需要构造方法来给属性赋值才能使用
3.4、@Resource注入(搭配)
@Resource注解也是可以有@Autowired注解的作用,进行属性注入,Setter注入,但是它不能给构造方法上加@Resource注解,会报错(不支持)
这里简单的使用一下,其实就是注解替换了将@Resource注解替了@Autowired注解
那都有@Autowired注解还要@Resource注解干什么??
3.5、@Resource与@Autowired区别
<1>来源不同:@Autowired来源于SPring,而@Resource来源于JDK的注解
<2>适用参数不同,@Autowired注解没有参数就是必须进行对象注入的,@Resource注解就不一样了,支持更多的参数设置,根据名称获取Bean对象(这里我们来看一下Resource注解中有多少参数可以使用)
有多个参数可以配合特殊情况使用,大部分情况下两者都是可以使用的(也就意味着可以交替使用)
<3>@Autowired可以搭配使用三种对象注入方式,而Resource注解只能搭配使用两种对象注入方式,不能用于构造函数注入