kran

@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 的某些问题的解决, 某些实现的方法, 也能在一定程度上证明它的文档的缺失. 话说回来, 它的文档描述的更多的是自己创造的问题/概念, 这很难说它的文档很好.