node js 各类数据库常用方法封装的心路历程

Posted wzj5cnaz

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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文档

以上是关于node js 各类数据库常用方法封装的心路历程的主要内容,如果未能解决你的问题,请参考以下文章

React+Immutable.js的心路历程

学习JS的心路历程-声明

学JS的心路历程 - JS的Class

cz-git 强大的 commitizen 的适配器——我的开发心路历程

学习JS的心路历程-参数的传递(下)

python热点wifi自动认证用于公司打卡源码+开发心路历程demo(精品)原价2500(文件较大)