请参考： https://github.com/xuanbg/gateway 里面的实现

SE 已入手，对比 6S，真香。当然和 11 是不能比的。

续航还好吧，1 天 1 充的节奏。

@Rxianbei 除了少数会造轮子的程序员和你这样的会用轮子的程序员外，更多的其实是第三种：除非有人告诉他，否则就不知道用什么轮子的程序员……

发期刊难道不是走导师的路子才是正确的打开方式么？楼主你居然连征求导师的意见都没有就去发……

正规的做法是 2 楼的方案。当然 1 楼的也能用，但不推荐。

返回使用不同的 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 文件，所以一点也不影响。

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

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

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

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

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