我天天用，都不知道 iPhone 有什么问题……

我相信楼主说的那么多问题可能是真有那么多。但这些问题对于我来说是不存在的，所以这些问题完全不会困扰我。我相信那么多 iPhone 的用户中，绝大多数是和我一个情况。

不要想太多。在古代或国外，社会底层要完成阶级跃升，一般都要靠几代人的共同努力。现在国内一代人就能完成，已经很快很快了，不要不知足。

请参考： 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 文件，所以一点也不影响。