nest后端开发实战(二)——分层

前言

分层是解决软件复杂度很好的方法,它可以下降耦合、增长复用。典型的java后端开发大多分为三层,几乎成了标准模式,可是node社区对于分层的讨论却不多。node后端是否须要分层?如何分层?本文将从我的的角度提供一些思路。前端

是否必要分层?如何分层?

我的的结论是:若是想作一个正儿八经的node后台应用,必定须要分层,java的三层架构,一样适用于node。结构以下:
clipboard.pngjava

dao层

dao(data access object),数据访问对象,位于最下层,和数据库打交道。它的基本职责是封装数据的访问细节,为上层提供友好的数据存取接口。通常是各类数据库查询语句,缓存也能够在这层作。node

不管是nest仍是egg,官方demo里都没有明确提到dao层,直接在service层操做数据库了。这对于简单的业务逻辑没问题,若是业务逻辑变得复杂,service层的维护将会变得很是困难。业务一开始通常都很简单,它必定会向着复杂的方向演化,若是从长远考虑,一开始就应该保留dao层。mysql

分享两点dao层的建议:git

一、以实体为中心定义类型描述。
后端建模的一大产出是领域实体模型,后续的业务逻辑其实就是对实体模型的增删改查。利用ts对类型的丰富支持,能够先将实体模型的类型描述定义出来,这将极大的方便上层业务逻辑的实现。我通常会将实体相关的类型、常量等都定义到一个文件,命名为xxx.types.ts。定义到一个文件的好处是,编码规范好落实,书写和引用也很是方便,因为没有太多逻辑,即便文件稍微大一点,可读性也不会下降太多。github

用po和dto来描述实体及其周边。po是持久化对象和数据库的表结构一一对应;dto数据传输对象则很灵活,能够在丰富的场景描述入参或返回值。下面是个user实体的例子:算法

// user.types.ts

/**
 * 用户持久化对象
 */
export interface UserPo {
    id: number;
    name: string; // 姓名
    gender: Gender; // 性别
    desc: string; // 介绍

}
/**
 * 新建用户传输对象
 */
export interface UserAddDto {
    name: string;
    gender?: Gender;
    desc?: string;
}
/**
 * 性别
 */
export enum Gender {
    Unknown,
    Male,
    Female,
}

虽然ts提供了强大的类型系统,若是不能总结出一套最佳实践出来,一样会越写越乱。全盘使用不是一个好的选择,由于这样会失去不少的灵活性。咱们须要的是在某些必须的场景,坚持使用。sql

二、不推荐orm框架
orm的初心很好,它试图彻底将对象和数据库映射自动化,让使用者再也不关心数据库。过分的封装必定会带来另一个问题——隐藏复杂度的上升。我的以为,比起查询语句,隐藏复杂度更可怕。有不少漂亮的orm框架,好比java界曾经很是流行的hibernate,功能很是强大,社区也很火,但实际在生产中使用的人却不多,反却是一些简单、轻量的被大规模应用了。并且互联网应用,对性能的要求较高,所以对sql的控制也须要更直接和精细。不少互联网公司也不推荐使用外键,由于db每每是瓶颈,关系的维护能够在应用服务器作,因此orm框架对应关系的定义不必定能用得上。数据库

node社区有typeorm,sequelizejs等优秀的orm框架,我的其实并不喜欢用。我以为比较好的是egg mysql插件所使用的ali-rds。它虽然简单,却能知足我大部分的需求。因此咱们须要的是一个好用的mysql client,而不是orm。我也造了一个相似的轮子bsql,我但愿api的设计更加接近sql的语意。目前第一个版本还比较简单,核心接口已经实现,还在迭代,欢迎关注。下面是user.dao的示例。json

import { Injectable } from '@nestjs/common';
import { BsqlClient } from 'bsql';
import { UserPo, UserAddDto } from './user.types';
@Injectable()
export class UserDao {
    constructor(
        private readonly db: BsqlClient,
    ) { }
    /**
     * 添加用户
     * @param userAddDto
     */
    async addUser(userAddDto: UserAddDto): Promise<number> {
        const result = await this.db.insertInto('user').values([userAddDto]);
        return result.insertId;
    }
    /**
     * 查询用户列表
     * @param limit
     * @param offset
     */
    async listUsers(limit: number, offset: number): Promise<UserPo[]> {
        return this.db.select<UserPo>('*').from('user').limit(limit).offset(offset);
    }
    /**
     * 查询单个用户
     * @param id
     */
    async getUserById(id: number): Promise<UserPo> {
        const [user] = await this.db.select<UserPo>('*').from('user').where({ id }).limit(1);
        return user;
    }
}

从广义的角度看,dao层很像公式“程序=数据结构+算法”中的数据结构。“数据结构”的实现直接关系到上层的“算法”(业务逻辑)。

service层

service位于dao之上,使用dao提供的接口,也能够调用其它service。service层也比较简单,主要是弄清其职责和边界。

一、实现业务逻辑。
service负责业务逻辑这点毋庸置疑,核心是如何将业务逻辑抽象成接口及其粒度。service层应该尽可能提供功能相对单一的基础方法,更多的场景和变化能够在controller层实现。这样设计有利于service层的复用和稳定。

二、处理异常。
service应该合理的捕获异常并将其转化成业务异常,由于service层是业务逻辑层,他的调用方更关心业务逻辑进行到哪一步了,而不是一些系统异常。

在实现上,能够定义一个business.exception.ts,里面包含常见的业务异常。当遇到业务逻辑执行不下去的问题时,抛出便可,调用方既能根据异常的类型采起行动。

// common/business.exception.ts
/**
 * 业务异常
 */
export class BusinessException {
    constructor(
        private readonly code: number,
        private readonly message: string,
        private readonly detail?: string,
    ) { }
}
/**
 * 参数异常
 */
export class ParamException extends BusinessException {
    constructor(message: string = '参数错误', detail?: string) {
        super(400, message, detail);
    }
}
/**
 * 权限异常
 */
export class AuthException extends BusinessException {
    constructor(message: string = '无权访问', detail?: string) {
        super(403, message, detail);
    }
}

对于业务异常,还须要一个兜底的地方全局捕获,由于不是每一个调用方都会捕获并处理异常,兜底以后就能够记录日志(方便排查问题)同时给与一些友好的返回。在nest中统一捕获异常是定义一个全局filter,代码以下:

// common/business-exception.filter.ts
import { ExceptionFilter, Catch, ArgumentsHost } from '@nestjs/common';
import { BusinessException } from './business.exception';

/**
 * 业务异常统一处理
 */
@Catch(BusinessException)
export class BusinessExceptionFilter implements ExceptionFilter {
    catch(exception: BusinessException, host: ArgumentsHost) {
        const ctx = host.switchToHttp();
        const response = ctx.getResponse();
        response.json({ code: exception.code, message: exception.message });
        console.error(// tslint:disable-line
            'BusinessException code:%s message:%s \n%s',
            exception.code,
            exception.message,
            exception.detail);
    }
}
// main.ts
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { BusinessExceptionFilter } from './common/business-exception.filter';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  // 注册为全局filter
  app.useGlobalFilters(new BusinessExceptionFilter());
  await app.listen(3000);
}
bootstrap();

三、参数校验。
dao层设计很简单,几乎不作参数校验,同时dao也通常不会开放给外部直接调用,而是开放service。因此service层应该作好参数校验,起到保护的做用。

四、事务控制。
dao层能够针对单个的持久化作事物控制,粒度比较小,而基于业务原则的事物处理就应该在service层。nest目前貌似没有在service层提供事务的支持。接下来我准备作个装饰器,在service层提供数据库本地事物的支持。分布式事务比较复杂,有专门的方法,后面有机会再介绍。

controller层

controller位于最上层,和外部系统打交道。把这层叫作“业务场景层”可能更贴切一点,它的职责是经过service提供的服务,实现某个特定的业务场景,并以http、rpc等方式暴露给外部调用。

一、聚合参数
前端传参方式有多种:query、body、param。有时搞不清楚到底应该从哪区,很不方便。我通常是自定义一个@Param()装饰器,把这几种参数对象聚合到一个。实现和使用方式以下:

// common/param.ts
import { createParamDecorator } from '@nestjs/common';

export const Param = createParamDecorator((data, req) => {
    const param = { ...req.query, ...req.body, ...req.param };
    return data ? param[data] : param;
});

// user/user.controller.ts
import { All, Controller } from '@nestjs/common';
import { UserService } from './user.service';
import { UserAddDto } from './user.types';
import { Param } from '../common/param';

@Controller('api/user')
export class UserController {
    constructor(private readonly userService: UserService) { }

    @All('add')
    async addUser(@Param() user: UserAddDto) {
        return this.userService.addUser(user);
    }

    @All('list')
    async listUsers(
        @Param('pageNo') pageNo: number = 1,
        @Param('pageSize') pageSize: number = 20) {
        return this.userService.listUsers(pageNo, pageSize);
    }
}

二、统一返回结构
一个api调用,每每都有个固定的结构,好比有状态码和数据。能够将controller的返回包装一层,省去一部分样板代码。下面是用Interceptor的一种实现:

// common/result.ts
import { Injectable, NestInterceptor, ExecutionContext } from '@nestjs/common';
import { Observable } from 'rxjs';
import { map } from 'rxjs/operators';

export interface Response<T> {
    data: T;
    code: number;
    message: string;
}

@Injectable()
export class ResultInterceptor<T>
    implements NestInterceptor<T, Response<T>> {
    intercept(
        context: ExecutionContext,
        call$: Observable<T>,
    ): Observable<Response<T>> {
        return call$.pipe(map(data => ({ code: 200, data, message: 'success' })));
    }
}

全部的返回将会包裹在以下的结构中:
clipboard.png

三、参数校验仍是留给service层吧
nest提供了一套针对请求参数的校验机制,功能很强大。但使用起来会稍微繁琐一点,实际上也不会有太多复杂的参数校验。我的以为参数校验能够统一留给service,assert库可能就把这个事情搞定了。

小结

本文讲的都是一些很小的点,大可能是既有的理论。这些东西不想清楚,写代码时就会很是难受。你们能够把这里当作一个规范建议,但愿能提供一些参考价值。

上一篇:nestjs后端开发实战(一)——依赖注入

相关文章
相关标签/搜索