为什么我停止使用Spring

我在DZone上有关Humble Architects的帖子引发了一些争议，尤其是围绕我对Spring和依赖注入框架的贬低评论。 在这篇文章中，我扩展了我停止使用Spring的内容。

我是挪威Spring的最早采用者之一。 我们开发了一个大型系统，最终我们不得不开始考虑诸如XML重用的不同机制之类的事情。 最终，它演变为@Autowire和component-scan，解决了巨大的配置文件的问题，但相应地降低了推理整个源代码的能力-而是将开发人员隔离在应用程序的一个很小的地方。

由于文化，工具，文档或其他一些东西使开发人员在不必要的层上建立不必要的层，因此应用程序的复杂性趋于蓬勃发展。

后来，我尝试在没有依赖关系注入框架的情况下构建应用程序，但是带走了有关何时使用“ new”，何时具有setter或构造函数参数以及哪些类型适合用作依赖项以及哪些类型与之耦合的课程。基础设施。

因此，我发现DI容器给我的一些直觉使我改进了设计，但与此同时，我发现当我卸下容器时，解决方案变得更小（很好！），更易于导航并且了解并且更容易测试。

这让我陷入了困境。 我发现使用该容器的成本非常高–它为增加复杂性和尺寸以及降低一致性提供了动力。 但是同时，它也教会了我一些良好的设计技巧。

最后，对我而言，创建一个连贯的小型系统比创建一个仅在解耦情况下已解耦的系统具有更高的价值。 连贯性和去耦性是相反的力量，我站在连贯性的一边。

同时，我发现依赖注入的文化非常喜欢重用。 但是重用确实会引入耦合。 如果模块A重用模块B，则模块A和B耦合。 B的更改可能会影响A更好（错误修复）或更糟（引入的错误）​​。 如果重用节省的成本很高，那么这是值得权衡的。 如果节省的成本很低，事实并非如此。

因此，重用和解耦是相反的力量。 我发现自己处于脱钩状态。

发生冲突时，我将一致性视为重耦合，将重耦合视为重耦合。 使用Spring的文化似乎具有相反的价值观。

参考： 为什么我停止在我们的JCG合作伙伴 Johannes Brodwall的“在更大的盒子内思考”博客中使用Spring 。

翻译自: https://www.javacodegeeks.com/2013/12/why-i-stopped-using-spring.html