看代码,觉得没必要再去封装一次。
或许?是我功力还不够,还没有认识到这种写法的好处?
1
linshuizhaoying 112 天前
你还是多学习吧。。。
|
2
belin520 112 天前
你直接业务层操作 uni.storage 不妥吧
|
3
retrocode 112 天前
封装一下, 便于打 log 和序列化呀, 你没看把 json 单独拎出来做了非空校验了吗
|
4
7gugu 112 天前 1
这样子是为了能够把底层的操作接口跟业务逻辑抽离开,假设未来需要更换底层的接口或者需要增加额外的逻辑,就不用在跳到每个调用 localstorage 的地方来修改,只要统一修改一次,过一遍业务逻辑的测试就可以了,节约了开发的工作量。
|
5
bojackhorseman 112 天前
|
6
CSM 112 天前 1
这就是过度封装了,“假设未来 XX”属于典型的过度设计。先不说这个假设有多大可能会实现(应该几乎不会遇到要更换 localStorage 为其他存储类型吧),就算未来要修改,那个时候再考虑封装也不迟,因为那个时候有更多的信息。修改起来就是个查找替换罢了。
`JSON.parse()` 也完全不用 try...catch, 原因是 catch 住然后呢,再原样抛出还是返回 null ? localStorage 里是自己之前保存的数据,如果这里出问题那说明逻辑上有问题,比如不是 JSON 却用了 `getJson()` 来获取。 |
7
haihaishuaige 112 天前 1
很有必要,公司有一个本地修改数据保存的 demo 项目,之前都是在单个页面用 localStorage 的,现在太多了想换别的缓存方案,由于页面太多一直没改,如果是封装的话只需要改一个地方就行
|
8
Niphor 112 天前
如果是一次性项目 那没啥必要
如果是常用的公共代码,起码 在这里 你可能统一加 prefix 、ttl 处理,更换实现等等而不必担心哪里漏了... |
9
renmu 112 天前 via Android
减少读取写入 json 的样板代码而已
|
10
k9982874 112 天前 via Android
屏蔽底层实现细节,留出了足够的扩展空间,同时涉及到的代码量不大,是个好设计
|
11
7gugu 112 天前
@CSM 你没遇到过,不代表这就是过度封装。
1. 首先逐个替换永远存在遗漏的可能性。其次,等到需要用的时候再替换,这里就已经存在额外的开发成本了,提前设计好,改一次全局就能生效的,非要额外花人力去单独调整,这就是在浪费自己的时间。如果你热爱加班,确实是可以这么做的。 2. JSON.pase 肯定是要加 try...catch 的,出错你可以增加上报,可以加重试逻辑,可以返回默认值,也可以继续抛出异常。而不是等到外网爆炸了卡住了,才跑过来修复问题。 |
12
toesbieya 112 天前
就代码而言写的确实不行,uni storge 自己就做了序列化和反序列化,根本不需要自己写 JSON 序列化
一般都是记录做了存储的键名,或者单独给某个数据做封装 |
13
iv8d 112 天前
方便切换,挺好的,建议回炉
|
14
lichuyi 112 天前
封装的太简单了
|