乐趣区

关于node.js:node-js-各类数据库常用方法封装的心路历程

这是我写出 access-db 办法库所经验的一个过程,在这里记录下吧

想法的诞生

小公司的倒退原本就不易,老本方面,是能有多节约就多节约。有时多集体干的事转由一个人干,也是毫不奇怪
。也是在这种状况下,我缓缓的成了全栈开发。

最后为了省钱,外加咱们只做小程序,就抉择了第三方云服务商作为后盾。刚开始还好,前面久了,发现他们提供的接口办法应用起来并没有想像的那么轻松。特地是在简单查寻的状况下,代码太过简单,不易读,批改起来也不不便。于是我就开始思考怎么去简化他的查寻。上面这个查寻办法,就是封装的最后版,能够看到,fetchFindByCheck应用起来也并不是那么的简略,并且,它还只能反对最简略的 andor 查寻,代码的可读性和灵活性都不高。

fetchFindByCheck({
  tableName: app.table.active_sign,
  relationship: ['and', 'and'],
  way: ['in', 'compare', 'compare'],
  params: [{ key: 'child_id', value: childID},
    {key: 'active_id', operator: '=', value: that.aid},
    {key: 'is_delete', operator: '=', value: false},
  ],
  limit: 30,
  page: 1,
  order_by: '-created_at',
  expand: [],}).then((res2) => {
  let tempJoined = res2.data.objects
  console.log('tempJoin', tempJoined)
},(err)=>{})

但即使如此,我还是封装了一套最简略的办法。

minapp-fetch 呈现

用过云服务的必定都晓得,云服务有很多类别的接口。就比方微信云开发,它会提供小程序端的接口、云函数的接口、甚至 web 接口。咱们抉择的云服务商,刚开始用得还好,前面因为业务多样化,咱们又面临不得不应用 web 的状况。而且,云服务商提供的 web 接口也和小程序下面的调用形式不一样,就导致即便同样的查寻,也要写两套不同的查寻办法。如果你还要用他的云函数、或者其余端的 api,那更是让你头大。

怎么办呢?为了加重开发和保护难度,进步开发效率。我产生了一个大胆的想法:要是能把各个端的接口都对立成一种,那不就很简略了吗。想法是好的,但实现起来就没那么容易了。最后在写 web 端的接口时,我好几次都想放弃,感觉把这些不同的写法,对立成一种,真的是有点难。因为你岂但要尽可能的保障同一种增删改查,在不同端失去的后果是一样的,还要通过算法,保障封装的办法尽可能的简略。

通过一段时间的奋斗,办法终于进去了,这个时候,我给它取了一个名字,叫做 minapp-fetch,当初也公布在了 npm 上,但它只反对咱们应用过的云服务商的 api。它的写法更加简洁,如下:

fetchFind(app.table.question, {
  p1: {
    way: 'compare',
    data: ['status', '>', 0]
  },
  p2: {
    way: 'compare',
    data: ['is_admin_answered', '=', false]
  },
  p3: {
    way: 'compare',
    data: ['is_admin_read', '=', false]
  },
  r: 'p1 && (p2 || p3)',
  page: commen.page,
  limit: commen.limit,
  order_by: '-created_at',
  expand: ['created_by']
})

其中,p参数为每一个小条件,r为小条件的 and、or,page为翻页,limit为每页数量,order_by为排序。尽管此时看着是比拟清晰了,但它还是有有余的中央。首先,p条件写法,还是有些繁琐;其次,就是 r 规定外面,不反对括号嵌套;再就是,它反对的办法也不多。

面对下面的种种问题,当然是解决了。通过前面的致力,minapp-fetch 才有了当初的写法:
其中,p参数对应的定义是这样的:p*: ['字段', '查寻办法', '查寻内容'],数组第一个参数为表里的字段,第二个参数为查寻办法,第三个参数及前面的,就是查寻的内容。

let rule = 'p3 || p7'

minapp.find(table, {p1: ['cat_label1', 'in', userChannels=[]],
  p2: ['cat_label2', 'stringLength', 23], // 查寻字符串长度为 23 的
  p4: ['cat_label2', 'stringLength', 23, 100], // 查寻字符串长度在 23 到 100 的
  p3: ['id', 'notIn', history],
  p7: ['status', '=', 20],
  p8: ['name', 'matches', /^foo/i],
  p15: ['geo_point', 'include', [15, 15]], // 坐标点,经纬[longitude, latitude]
  p21: ['geo_point', 'withinCircle', [15, 15], r], //r 单位 km
  p23: ['geo_point', 'withinRegion', [15, 15], max_r], //max_r, min_r 单位为 m
  p28: ['geo_point', 'within', [0, 0], [6, 0], [6, 9], [0, 9], [0, 0]], // 坐标点集,首点 = 尾点,经纬[longitude, latitude]
  p63: ['content', 'isNull', true],
  p93: ['content', 'isExists', false],

  r: isSelect ? rule : '(p1 && (p2 || p3)) && (p57 && p93)',
  page: 1, // 默认值
  limit: 20, // 默认值
  orderBy: '-created_at', // 默认值
  expand: [], // 默认值
  select: [], // 默认值
  withCount: false, // 默认值
})

能够看到,下面的 find 办法,曾经相当简单了,但它给人的感觉,还是很清。你甚至能够随便更换 r 规定,进行不同状况的查寻。(查寻最终是按 r 规定 来的)

access-db 呈现

再起初,因为云服务商的一些有余,外加咱们本人也对业务灵活性有更多要求,所以决定本人写后盾了。缓缓的,咱们逐步开始放弃云服务商,本人开发。此时问题也来了,数据库的连贯各不相同,习惯了 minapp-fetch 写法的我,再去独自用数据库的连贯办法,感觉的确不习惯。并且,不同类型的数据库,办法也不一样,保护和转化,成了一大难题。你必定也猜到了,没错,就是把数据库的连贯,也封装起来!

从 node.js 最火的非关系型数据库 mongodb 动手,开始了数据库办法封装的旅程。说切实的,mongodb的根本办法和之前云服务商的 webapi 很类似,也没费太多的功夫就实现了罕用办法的封装。但前面退出第二个数据库 mysql 时,问题就来了。因为 mysqlsql 语句 进行查寻的,和之前的齐全不一样。也就是说,必须要通过算法,将封装的写法,转换成 sql 语句。你可能会感觉,应该不简单,就是一个简略的组成字符串而已。当初我也是这么认为的,但当我开始动手研发时,才发现,问题远比这个简单。对 mysql 理解的同学应该晓得,sql 语句能够重命名、能够连表查寻、能够嵌套查问、聚合查寻等,并且为了使查寻正确,往往还要对表和字段进行更名,再援用等等,这些问题就使得转化难度大大提高了。可能有时候,你满足了其中一种查寻,却让另一种查寻出了问题。但为了平时开发得更爽,更高效;我还是硬着头皮去实现它。

通过一段时间的苦熬,她终于开始有个样子了,我又从新发了一个 npm 包,给了她一个全新的名字:access-db,至此,你甚至能够同时援用多种数据库,进行关联应用:

import {mysql, mongodb, fastdb} from 'access-db'

async function exp() {let {data} = await mongodb.get('table11', id)
  
  await mysql.find('table2', {p0: ['num', '=', data.num],
    r: 'p0'
  })
}

因为每一种数据库,都有本人的特点,所以,封装的办法外面,必定会有个体差异,这也无奈防止。

Fastdb 呈现

仔细的同学可能发现了下面的代码中,引入了一种新的数据库 fastdb,是的,它是access-db 内置的,本地 json 数据库。也是我发现有相似的本地数据库后,本人开发的。它的长处就是,齐全应用 access-db 语法进行增删改查,同时,不须要你装置任何额定数据库,间接能够用,很不便。毛病也很显著,存储的模式是 json 文件,没有数据库明码这些,不平安,数据量大了,查寻效率也不是那么高。

结语

我心愿通过记录本人的这些经验,能带给你些启发或共鸣。我不是什么大神,可能你也不是,但只有本人不停下思考的脚步,并敢于去实现它,那你也肯定能做出有意义货色进去!

将这个办法库,献给那些须要的敌人:
access-db 包
access-db 文档

退出移动版