1、你在项目中的数据访问层是否还长这样?
随着我年纪的增长,我思考了2个问题:
1、如果有同事因为不仔细,把元数据写错了怎么办?
2、能不能不用每次都去写这些元数据代码?
2、从Nest.js或者Spring MVC框架中得到的一些启示。
如果我们前端的数据访问层也能写成如nest.js的这种风格,那么,我们的代码看起来将会是相当的简洁。所以,从这个例子,我们已经确定了我们的设计目标,如果我们能得到一组装饰器,那么,我们的数据访问层将会改写为以下形式:
3、回到原点,背上行囊,从装饰器出发。
这是一段摘录自阮一峰老师的《ES6入门》一书的话:
装饰器是装饰模式在语法层面的提供,通过装饰器,我们可以在某个横切面完成我们的业务逻辑,如预判,如果不满足,直接终止该方法的执行,或执行方法之后,需要的一些补救行为。这些横切面跟我们的业务代码没有或者少有耦合,更容易帮助我们编写出优秀的软件系统。
装饰器其实就是一个普通的函数,写成@ + 函数名,放在类名或者类的成员方法(或属性)名之前,因为有变量的提升,普通函数不能被装饰。目前ES支持两种类型的装饰器。
3.1、类装饰器
类的装饰器接收一个参数,target,这个target就是类本身。
3.2、 方法(或属性)装饰器
方法的装饰器有3个参数,顺序分别是target,prop,descriptor,第一个参数target是被装饰类的原形对象,第二个参数是被装饰方法或属性的字段名,第三个参数是一个descriptor,它的类型是PropertyDecorator。由于笔者在之前的博文有讲解过这个类型,因此,此处仅贴出它的类型定义代码 不再详细讲解,不太了解的读者可参考MDN或笔者早先的博文。
PropertyDescriptor的定义如下:
4、编写装饰器
4.1、 前置知识,reflect-metadata库
GitHub地址:reflect-metadata
我们不应该修改语言本身的定义以外的属性(如给descriptor加一些奇奇怪怪的字段,或者直接在function定义一些奇奇怪怪的字段,或者在Object,或者自己去是现实一个记录元数据的对象等),否则可能会给我们的程序带来潜在的隐患。reflect-metadata可以给我们提供这些便利,使用这个库以后,可以方便的记录我们传递的元数据参数。
4.2 、装饰器的实现
根据笔者在3年项目开发中对axios的使用感受,提炼出了以下方法:
在数据访问类中使用:
因为我们的数据访问层现在是按照装饰器这种风格写的,由于目前ES还不支持参数装饰器(TS支持),当我们传递多余一个参数或者传递一个基本类型的参数时候,无法识别要传递给后台的key,因此,我们在调用的时候必须写成仅含有一个参数,且这个参数必须是对象的这种统一格式,多少还是有一点儿遗憾。?
5、总结
1、借助装饰器,我们可以少写很多代码,简化我们的开发。
2、在日常的开发中,我们绝大部分场景都在写url,可以避免因单词的拼写错误,导致数据传递出错的问题。
由于笔者水平有限,写作过程中难免出现错误,若有纰漏,请各位读者指正,你们的意见将会帮助我更好的进步。本文乃笔者原创,若转载,请联系作者本人,邮箱404189928@qq.com?
常见问题FAQ
- 免费下载或者VIP会员专享资源能否直接商用?
- 本站所有资源版权均属于原作者所有,这里所提供资源均只能用于参考学习用,请勿直接商用。若由于商用引起版权纠纷,一切责任均由使用者承担。更多说明请参考 VIP介绍。
- 提示下载完但解压或打开不了?
- 找不到素材资源介绍文章里的示例图片?
- 模板不会安装或需要功能定制以及二次开发?
发表评论
还没有评论,快来抢沙发吧!