返回使用不同的 dto 即可，不同类型的转换可以用 A 对象序列化后再反序列化为 B 来转，不需要一个个 get/set

是的，做前端无论你用传统的 jQuery 还是流行的 VUE 什么的，MVVM 模式都是要搞起来的。一旦开发模板磨合出来了，开发新页面简直就是流水线生产一样高效。

事实上我连古老的 Winform 都搞起了 MVVM 模式。控件拖拖完成一个 View，里面坚决不写一行代码。然后搞一个 ViewModel 类，构造方法里面专门写数据双向绑定的代码，和界面交互的事件绑定，一般都是几个方法实现一下事件触发后的交互逻辑，百十来行代码就搞定。然后再来个 Model 类，就负责构造 ViewModel 和转发数据，通常也就几十行代码完事。

这样分割后最大的好处是代码结构通用化和模板化，一些公共的处理逻辑就可以提取出来，搞几个基类，让业务类去继承一下，就可以少写很多很多的代码。

@FanError 对的，确实性能不好，但我们的业务每天新增的数据都是以百千计而非百万千万计……所以我就不管他性能好不好了，只要用的方便就好。真香

这不是 hash 算法大干快上的时候么？客户端算一个哈希上传，服务端也算一个哈希出来比对就行了呀。只是需要注意双方计算哈希的时候，对象序列化后属性的顺序可能不一致的问题。

@JaguarJack A 和 B 之外搞个 Common 就行，AB 都依赖 C

@abcbuzhiming 功能边界肯定要划分清楚的呀。

我在带团队的过程中一直强调，把代码写对地方比写对代码更重要。代码写错了很快就能发现并修复问题，写错了地方则不然，当时是没问题你好我好大家好，但会让你在后面一直吃屎。。。同时也会在合并分支时产生大量的冲突。

事实上只要在写代码之前稍微思考一下再动手，就很容易解决功能边界的问题，也就能把代码写对地方了。

直接仲裁就是了，稳赢。

无脑选 2 就行。第一种非常容易写着写着就不清不楚地黏糊在一起了

@Acoolda 所以学的时候要多想想怎么用呀，想明白了就学到了，想不明白就是白学，浪费时间。

结果等效，但执行计划不一定相同

我们的文档就基本上是 MD，和代码在一个仓库，这样比较方便。不是 MD 的除了流程图外，都是不会更新的。流程图也是个 xml 文件，所以一点也不影响。

现在买电车，要有两个前提条件：一、有车位；二、车位能装充电桩。

电车平常开开还是很好的，但我这种没车位的就只能望洋兴叹了。

学以致用，效率才会高。学了没用，等于白学。

一、学的时候想明白怎么用，并且去用；二、遇到问题了，想明白学什么能解决问题。

做到这两点，就能学以致用。

目前用 Linux 桌面的都是瞎折腾。。。。。。不接受反驳

互联网已经是最容易上升的行业了……如果做互联网都不能脱颖而出，做教师、医生、公务员的话，也就是底层混一辈子的料。

第一个简单，开销也低，因为只管 insert 就行。第二种就要先读出来，然后拼接，然后 update 。不说数据库操作 select +update(delete+insert)比 insert 开销大得多，业务逻辑也复杂了很多。省那么点存储空间，脑子瓦特了……

数据库要支持 1 万并发写还是很费钱的……别的都是小 case