tech notes

2021-09-13 约 1947 字预计阅读 4 分钟

about some tech marked

1. spring boot

1.1. PostMapping 属性

name
value 请求路由地址
path 指定路由地址
params 指定request中必须包含某些参数值
headers 指定request中必须包含某些指定的header值
consumes 请求提交内容类型，MediaType方式，如 application/json、application/x-www-urlencode、multipart/form-data等
produces 请求返回的数据类型，仅当request请求头中的(Accept)类型中包含该指定类型才返回，如application/json

demo:

@PostMapping(value = "/admin", consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE)
public ResponseEntity<Object> postPCWithJson(@RequestBody Object body,HttpServletRequest request, HttpServletResponse response, HttpMethod httpMethod) throws URISyntaxException {
    // TODO
    return new ResponseEntity("", HttpStatus.OK);
}

demoNieyan:

@ApiOperation(value = "获取文章记录", httpMethod = "POST")
@PreAuth("permitAll()")
@PostMapping(value = "/query", produces = "application/json;charset=UTF-8")
public R<PageInfoView<InnerHits<ArticleListVO>>> queryNews(@RequestBody QueryArticleParam queryArticleParam, Query query) {
    PageInfoView<InnerHits<ArticleListVO>> pageInfoView = openNewsService.queryOpenNewsInnerHits(queryArticleParam, query);
    return R.data(pageInfoView);
}

1.2. swagger2 注解

@Api：用在请求的类上，表示对类的说明
    tags="说明该类的作用，可以在UI界面上看到的注解"
    value="该参数没什么意义，在UI界面上也看到，所以不需要配置"
 
 
@ApiOperation：用在请求的方法上，说明方法的用途、作用
    value="说明方法的用途、作用"
    notes="方法的备注说明"
 
 
@ApiImplicitParams：用在请求的方法上，表示一组参数说明
    @ApiImplicitParam：用在@ApiImplicitParams注解中，指定一个请求参数的各个方面
        name：参数名
        value：参数的汉字说明、解释
        required：参数是否必须传
        paramType：参数放在哪个地方
            · header --> 请求参数的获取：@RequestHeader
            · query --> 请求参数的获取：@RequestParam
            · path（用于restful接口）--> 请求参数的获取：@PathVariable
            · body（不常用）
            · form（不常用）    
        dataType：参数类型，默认String，其它值dataType="Integer"       
        defaultValue：参数的默认值
 
 
@ApiResponses：用在请求的方法上，表示一组响应
    @ApiResponse：用在@ApiResponses中，一般用于表达一个错误的响应信息
        code：数字，例如400
        message：信息，例如"请求参数没填好"
        response：抛出异常的类
 
 
@ApiModel：用于响应类上，表示一个返回响应数据的信息
            （这种一般用在post创建的时候，使用@RequestBody这样的场景，
            请求参数无法使用@ApiImplicitParam注解进行描述的时候）
    @ApiModelProperty：用在属性上，描述响应类的属性

1.3. entity、VO、DTO

entity 里的每一个字段，与数据库相对应，

vo 里的每一个字段，是和你前台 html 页面相对应，

dto 这是用来转换从 entity 到 vo，或者从 vo 到 entity 的中间的东西。（DTO中拥有的字段应该是entity中或者是vo中的一个子集）

举个例子：

你的html页面上有三个字段，name，pass，age

你的数据库表里，有两个字段，name，pass ，注意没有 age。

而你的 vo 里，就应该有下面三个成员变量，因为对应 html 页面上三个字段。

// vo
private string name；
private string pass; 
private string age;

这个时候，你的 entity 里，就应该有两个成员变量，因为对应数据库表中的 2 个字段。

// entity
private string name；
private string pass;

到了这里，好了，业务经理让你做这样一个业务年龄大于 20 的才能存入数据库，这个时候，你就要用到 dto 了，

你要先从页面上拿到 vo，然后判断 vo 中的 age 是不是大于 20。
如果大于 20，就把 vo 中的 name 和 pass 拿出来，放到 dto 中。
然后在把 dto 中的 name 和 pass 原封不动的给 entity，然后根据 entity 的值，在传入数据库。

这就是他们三个的区别。

PS： dto 和 entity 里面的字段应该是一样的，dto 只是 entity 到 vo，或者 vo 到 entity 的中间过程，如果没有这个过程，你仍然可以做到增删改查，这是根据具体公司规范来的。

1.4. DAO\Service\Controller

原文链接

DAO层： DAO层叫数据访问层，全称为data access object，属于一种比较底层，比较基础的操作，具体到对于某个表的增删改查，也就是说某个DAO一定是和数据库的某一张表一一对应的，其中封装了增删改查基本操作，建议DAO只做原子操作，增删改查。

Service层： Service层叫服务层，被称为服务，粗略的理解就是对一个或多个DAO进行的再次封装，封装成一个服务，所以这里也就不会是一个原子操作了，需要事物控制。

Controler层： Controler负责请求转发，接受页面过来的参数，传给Service处理，接到返回值，再传给页面。

总结：个人理解DAO面向表，Service面向业务。后端开发时先数据库设计出所有表，然后对每一张表设计出DAO层，然后根据具体的业务逻辑进一步封装DAO层成一个Service层，对外提供成一个服务。

目录