spring 停止容器_为什么我停止使用Spring

spring 停止容器

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

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

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

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

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

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

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

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

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

发生冲突时，我重视一致性而不是脱钩，而不是重用。 使用Spring的文化似乎具有相反的价值观。

参考： 为什么我停止在JCG合作伙伴 Johannes Brodwall的Think in Bigger Box博客中使用Spring 。

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

spring 停止容器