移民不是问题的解决，而是问题的显形。

@zjsxwc “情”，“爱慕”，“相思”，为什么是忠贞。

然后，软弱庸俗臭不可闻。

@NoString 一个因地制宜道尽所有。有所思考的选择，和追随潮流的选择一定有所不同。哪怕结果一样。这时受制的是个人见识了，我亦在此列。结贴，睡觉。

@sagaxu ioc ，aop 我也每日使用，并且一样是通过注解的形式去使用。你说的很好，框架来实现概念，那就应该想清楚这个实现的边界。spring 对此的把握如何？他对注解是否在滥用？对 di+自动装配带来的影响是否有过反思？

是的，每一种技术都会被很多人学习记录，但总是要权衡一个值得的界限，在我这 JAVA 比 spring 更值得学习，所以我不死磕，也一样在 JAVA 的方向上。

我大概说清楚了吧。

最后，我相信在 java 里他们会加入 di ，因为 di 是真的解决问题的一个理念。但 flask 到 django 你真的认可吗？思考与不思考后选择 django 都截然不同，更不用说，在实践中组装出适合自己业务的框架。轮子是一定要造的，把所有轮子叫轮子没错，但都叫重新发明了“spring”，“django”就是傲慢。

@xuld 我倒是不反对设计模式, 一个程序员哪怕没有看过设计模式, 经过很多业务的折磨, 最终也会写出那些业务模式总结出来的形状. 不如说, 设计模式是一种业务表达的结果, 照搬设计模式去套业务才是该反省的地方.

@sagaxu 其实在上一个回复里最后那句才是真的值得考虑的, 延展开来就是, 一个框架提出了很多的概念, 在这些自创的概念上来补充使用文档, 而这些概念甚至实现到底是在解决问题还是制造问题? 我个人的看法是在 spring 身上, 已经完全超出了解决问题的范畴, 对自动装载或注解的执着, 造成最终考验使用者的不是 java 或编程技巧, 而是在其之上的专门经验, 这可能也是它的任何一个点都会被 blogger 一遍一遍的重复记录.

@wxw752 yes, 做技术最重要的是舒心~
不过并不是为了统一认知, 这在计算机的巴别塔中, 始终不曾存在.

@realpg 个人项目用自己熟悉的挺好的

@jeesk 大厂有大厂的规范, 作坊有作坊的打法, 个人更是各有喜好, 既然被代替是必然性, 那么考虑一下被什么样子的东西替代也是好的. 论文档的话, spring 的文档实在不值得恭维, 我说它赶不上 php 的文档都不算羞辱, 另外铺天盖地的博客文章来讲解 spring 的某些问题的解决, 某些实现的方法, 也能在一定程度上证明它的文档的缺失. 话说回来, 它的文档描述的更多的是自己创造的问题/概念, 这很难说它的文档很好.

@zed1018 说说个人看法, 和你相反, 参数验证在路由里才比较奇怪(仅数字那种不算), 参数在直观上应该属于业务的一部分(不完全准确), springboot 在请求处理方法的参数上加验证, 看起来有点强上注解的感觉. 当然了, 个人看法, 不必深究.

@xuld 我倒是觉得这个未来还比较远, 事实上 AI 对准确性的把握在目前正是弱点吧, 更不要说对业务的准确理解. 有句话说的好, "复杂度不会消失, 只会转移", 虽然这话需要一定的前提, 但你总要有输入才会有输出, 路由/验证/crud, 你总要通过某种途径告知"框架", 自然语言是不保险的, dsl 是另一种复杂度. 关于基建, 我对框架集成, 大多数时候是持否定态度, 暂时说到这, 有兴趣一起交流 [email protected]

@wxw752 与其说是 spring 的生态, 我更倾向于说 java 的生态比较丰富, 围绕注解和配置文件的封装到底是不是好事这值得商榷, 双份文档和打断调试逻辑也是各有见解吧.

带来工资的当然是好框架, 却不能证明不带来工资的是坏框架,哈哈

@bfjm 这个是最好的, 高端的食材不需要复杂的烹饪技巧. 按照自己的业务发展出一套编码标准是最牛逼的

@xuld 我的考虑和期待和你的结论一样, springboot 一定会跌下神坛.
你说的这些没毛病, 只是"为啥全球还有上百万的人学习那个框架？"这句话又给 springboot 做了注脚. 我个人认为, 人的选择除了不得不选也受限于能力/视野/审美/理念等等, 所以千奇百怪的解决方案层出不穷, 在此之上又带来无穷的问题, 在基于创造的问题再创造解决方案, 螺旋屎山由此拔地而起.
可惜没有说放下 java 的理由, 我想看看你选择的语言和设计的框架~