“工作中能解决的问题我都不觉得他有挑战性”

这还说不太敢吹，我觉得你在凡尔赛我。。。

小心碳酸，定期去检查下牙齿，有人牙比较好无所谓，如果牙不太好的话一定小心。

我们之前就是全部给到前端的。


不过中奖用户都是编的，哪有那么多真的中奖用户啊。。。

明明就是你自己想白嫖一个需求，没有得逞就给人家扣帽子
固执？理解错误？无脑反驳？
真把自己当产品经理了啊？？？

要十斤精肉，切作臊子，不要见半点肥的在上面。
再要十斤都是肥的，不要见些精的在上面，也要切做臊子。
再要十斤寸软骨，也要细细地剁做臊子，不要见些肉在上面。

@houshuu 现在想想感觉我们的语文课本就很科学，学一篇课文，课后就跟几个文中的生字，相当于一边学语法一边背单词了。

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