使用注解存储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: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