这是我在写access-db方法库时经历的一个过程。就记录在这里吧。这个想法的诞生并不容易。一方面，尽可能多地储蓄。难怪有时很多人做的事情会转移到一个人身上。也是在这种情况下，我慢慢的成为了一名全栈开发者。一开始为了省钱，而且我们只做小程序，选择了第三方云服务商做后台。一开始还好，时间久了，发现他们提供的接口方法并没有想象中那么好用。特别是在复杂搜索的情况下，代码过于复杂，难以阅读和修改。所以我开始考虑如何简化他的搜索。下面的搜索方法是包的初始版本。可见fetchFindByCheck使用起来并不是那么简单，只能支持最简单的and和or查找，代码的可读性和灵活性都不好。高的。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)=>{lettempJoined=res2.data.objectsconsole.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',数据:['is_admin_answered','=',false]},p3:{way:'compare',数据:['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,pageofthesmallcondition翻页，limit为每页数量，order_by为排序。虽然此时看起来清晰多了，但还是有不足之处。首先，p条件的写法还是有点繁琐；第二，在r规则中，不支持括号嵌套；第三，它不支持很多方法。面对以上问题，当然是迎刃而解了。经过后续的努力，minapp-fetch有了现在的写法：其中，p参数对应的定义如下：p*:['field','searchmethod','searchcontent'],第一个参数array是表中的字段，第二个参数是查找方式，第三个参数及后面的是查找内容。让规则='p3||p7'minapp.find(table,{p1:['cat_label1','in',userChannels=[]],p2:['cat_label2','stringLength',23],//搜索p4，字符串长度为23:['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]],//坐标点，经纬度[经度,纬度]p21:['geo_point','withinCircle',[15,15],r],//r单位kmp23:['geo_point','withinRegion',[15,15],max_r],//max_r,min_r单位为mp28:['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,//默认值限制:20,//默认值orderBy:'-created_at',//默认值Valueexpand:[],//默认值select:[],//默认值withCount:false,//默认值})可以看到，上面的find方法已经很复杂了，但是给人的感觉还是很清除。你甚至可以随意替换r规则，在不同的情况下进行搜索。（最终是按照r规则查找的。）access-db出现后，由于云服务商的一些不足，以及我们自己对业务灵活性有更多的要求，我们决定自己写后台。慢慢地，我们逐渐开始放弃云服务商，自己发展。这时候问题也来了，数据库的连接方式不一样，习惯了minapp-fetch的写法，再单独使用数据库的连接方式，感觉真的不习惯。而且，不同类型的数据库有不同的方法，维护和改造成为一大难题。你一定猜到了，没错，数据库的连接也被封装了！从node.js最流行的非关系型数据库mongodb开始，我们开始了数据库方法封装的旅程。说实话，mongodb的基本方法和之前云服务商的webapi很像，没费太多力气就完成了常用方法的封装。但是当后面添加第二个数据库mysql的时候，问题就来了。因为mysql是通过sql语句来查找的，跟前面的完全不一样。也就是说，必须通过算法将封装转化为SQL语句。你可能认为它不应该很复杂，它只是一个简单的字符串。我一开始也是这么想的，但是当我开始研发的时候，我发现问题远比这个复杂。熟悉mysql的同学应该都知道，SQL语句可以重命名、联表查询、嵌套查询、聚合查询等，而为了使查询正确，往往需要重命名表和字段，然后引用等等，这些问题使得转换难度大大增加。有时您满足一种类型的查询并导致另一个问题。但是为了平时的开发更酷更高效；我还是硬着头皮去体会。经过一段时间的努力，她终于开始看一看了。我重新下了一个npm包，给她起了一个全新的名字：access-db。到目前为止，你甚至可以同时引用多个数据库进行关联使用：import{mysql,mongodb,fastdb}from'access-db'asyncfunctionexp(){let{data}=awaitmongodb.get('table11',id)awaitmysql.find('table2',{p0:['num','=',data.num],r:'p0'})}因为每个数据库都有自己的特点，所以要有个别的封装方法的差异，这是无法避免的。fastdb出现细心的同学可能已经发现，在上面的代码中，引入了一个新的数据库fastdb。是的，它是一个内置的access-db，一个本地的json数据库。也是我发现本地有类似的数据库后自己开发的。它的优点是完全使用access-db语法进行增删改查。同时，它不需要你额外安装任何数据库，直接使用即可，非常方便。缺点也很明显。存储是json文件的形式，没有数据库密码等，不安全，数据量大，查找效率没那么高。结束语希望通过记录自己的这些经历，能够给大家带来一些启发或者共鸣。我不是大师，也许你不是，但只要你不断思考，勇于去实现，那你一定能做出有意义的事情！把这个方法库献给需要的人：access-dbpackageaccess-dbdocumentation
