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