所以不用 ENUM 的理由是什么？

@waibunleung #23 简单的项目结构里 model 充当 DAO 的设计很合理，轻便且能满足大部分需求

@waibunleung #18 是的，正常来说，把所有数据操作封装在一起（ DAO 类），好处远远大于开销，比如：

能方便的复用之前的逻辑，不用再复制粘贴一遍
可以快速查看在当前数据集上有哪些操作
调整下层数据结构或添加删除参数时不用去找每一个调用的地方
需要整个替换掉 ORM 时改动不会太大
测试时方便 mock 数据
等等等。

而开销仅仅是多几个 DAO 类。

哪怕只是为了让代码结构更清晰，这几个类都是有必要的。

用用户信息举例：

DAO 屏蔽了数据获取的逻辑，只提供一个 getUser(id) 的方法，不管里面怎么实现，需要数据用这个方法取就行。

然后看 DAO 内部，可以用很多方法去实现。

最简单的方法，直接查库，query('select * from users where id = ' + id)，然后返回数据，需要什么数据就直接写 SQL
ORM 就是把常用的 SQL 封装好，这样用里面提供的类似 getUserById(id) 的方法就能省掉上面的字符串拼接、参数处理、校验、返回数据格式化等问题，直接返回映射好的 object 。

当然，不一定所有数据都存在关系数据库里，也可能存在 nosql 数据库、磁盘文件甚至需要通过网络请求其他服务，但不管存在哪，为了最大限度的减少这些乱七八糟的逻辑对业务逻辑的影响，只提供统一的操作数据的接口，这个就是 DAO 干的活。

这个问题问的比较差，正常情况只有 room 和 user 的话，不可能把对 room 的操作放在 user 里，讨论题给了二择而且是答案很明显的二择。
问如何实现开关门操作才比较有讨论价值。
对此场景可以从 user 派生出具有对应身份职责的子类，封装相应的职责特殊操作，或者由 user 类向 room 发出命令，根据注册房间内部的权限信息来教研。

@feifanhanmc V2 点赞功能太不人性化了，自己的点赞有提醒，别人喷自己的点赞却没有，这样想一个一个喷回去太麻烦了，咱们一起给站长提建议加上这个功能吧🐶

后车的喇叭不就是么。。。
停在第二一般比第一急多了，绿灯准时按喇叭就算好的，我遇见过好多变灯提前一秒就开始按的

@hello2060 建议推荐给新疆朋友们

特效的话《环太平洋》
音乐的话《海上钢琴师》？
综合点的话《指环王》这种史诗大片应该不错

@Jirajine 很多团队里也有没技术含量但有大量重复体力劳动的位置，你找个技术好有追求的人家还看不上呢。。。
领导要是只看到“任劳任怨”就心生好感忽视技术水平了你应该歧视的是你的领导，勇敢炒了这种领导比你在背后弯弯绕绕更能对职场环境有所改善。

@Jirajine 你这人。。。非把自己看不上的人叫来问难一顿，贱不贱呐

这满满的优越感是怎么回事？技术不好的人就活该被你全方位无死角嘲讽？

首先，别人让你约你就约？你自己已经断定这个人所有方面你都看不顺眼，就因为其他人说了你就要把人家叫来浪费大家时间？就算你领导让你约，碰到这种情况更高效的方式不是讲清理由尽量拒绝？

保持客观理智，通过简历、笔试、面试等手段尽量的分析挖掘应试者的优缺点才是面试官该做的事。就算你觉得对方全是缺点，你应该做的是礼貌拒绝而不是一味否定他人，你才看过几份简历，行业的上下线远比你想的离谱，你可以在心里鄙视他一万遍，但是不要借着寻求建议的名义来倾倒垃圾情绪。。。

我觉得这个阀字传播开来是有原因的
两字写法粗看很相似，但“阈”在日常生活中基本没有使用，大部分人不熟悉，而“阀”是大家都比较熟悉的词，而且泄压阀之类的阀门是大家普遍了解的，这类实物和“阈值”所表达的临界值的意思是能直接关联起来被动记忆的，这种关联记忆是会不断强化的
我一直知道“阀值”这个词是错，平时大部分时间也有注意，但有些时候随口回答或其他不经过太多思考脱口而出的时候，偶尔还是会说这个错词

@Dukewill 我觉得这样才更有实感啊，骡子单机再超神，也难以影响战争走向，在国家机器面前，一两个 ACE 根本没有太大影响，只是在天时地利人和的情况下恰巧赶上某个决定性节点而被大家记住。。。
开始岛上靠落后的火器+残酷训练+高战损比才能勉强在家门口开开迷雾，现在看到了外面，真正科技夹持下的热兵器和国家级的资源供给，真的是能把这些精英巨人轰杀至渣的

@fuchunliu #31 西安
名义上：全国中心，中部交通枢纽
实际上：“西北人说西安不算西北”，“西南、南方、北方、东部地区也是这么说的...”

@flighter 感觉我们业务代码每月变动就不只 10% 😂

@julyclyde 额，确实我写草率了，应该是同一条线路可切换方向但不可同时传输。