在Twitter领域再次引起了一些反感 ，我看到了Sam Atkinson的博客帖子，题为“ 为什么我讨厌Spring” 。 这篇博客文章的撰写早于2014年，但是DZone后来才真正选择并发布了它。 实际上，在撰写本文时，Atkinson是一名开发人员，正在环球旅行。 因此，他个人对社交媒体一定感到非常惊讶。
Atkinson先生的文章触及了当前Java企业应用程序设计中的几个有趣的问题：XML配置和编译时安全性，魔咒，其他Spring应用程序上下文文件的导入和软件复杂性。 在这篇博客文章中，我将简要介绍这些内容。
我对XML配置并不感到惊讶，但是后来J2EE 1.3拥有处理EJB XML映射文件的可怕经历，因此Hibernate持久性在早期也是如此。 最终，Java SE 5注释和Java EE 5规范帮助改变了一切。 Ruby on Rails的CONVENTION-OVER-CONFIGURATION概念使Java进入了下一阶段。 Spring Framework早在2002年和2003年就以可行的依赖关系注入容器实现进入OSS市场。当时，J2EE 1.3 / 1.4令人震惊，混乱的是容器管理的会话EJB和混乱的实体EJB概念。 没有标准的DI框架，Spring的竞争对手是Pico Container ，更老的Apache Avalon（现在关闭）框架，甚至是Struts 1.x框架。
从2006年开始的几年后，Java EE出现并在编译时为Context and Dependency Injection（CDI）1.0提供了强大的类型安全性。 对于成千上万采用Spring Framework的企业而言，CDI为时已晚，当时大多数企业都在努力从Java 1.4（J2EE 1.4）迁移到Java 5和/或6。十年前的最大问题是使关键任务应用程序保持运行状态在WebLogic Server 7/8或IBM WebSphere 5/6应用程序服务器中。 因此，最先进的技术已经被打破了好几年。 Spring Framework拥有自己的DI容器，而Java EE 6也具有DI容器，因此永远不会碰面。
当它最初被构想时， 依赖注入早在2003年就已陷入僵局，当时花了很多时间才能理解面向对象系统的常见问题。 其中最主要的是应用程序的可测试性和Java对象的替代实现的选择。 在当时，通过将对普通旧Java对象（POJO）的实例化的控制权交给外部框架是非常不寻常的。
在水被打破之后，每个工程师都将类和实现推到了框架中，这很可能是我们现在为此付出的错误。 当软件运行时，注入哪些bean以及在哪个应用程序层运行的魔咒非常神奇，但是，就像Sam Atkinson所说的那样，当您追逐一个错误并通过Spring重构其他团队的依赖关系时，这真是一场噩梦框架。 除了通常的BIT-ROT的人为问题以及软件开发，SILO DIVISION工程的内部投资银行文化之外，Spring框架和其他应用程序框架总是在某个时候会丢失。
Sam Atkinson提到了大型应用程序代码库的典型LAYERING问题，尤其是当源代码分成数百个时。 或偶尔有组织内部成千上万的工程师，测试人员和架构师。 从1.0版开始，Spring框架就已经具有特殊功能， 可以通过在不同的Maven项目中放置不同的bean定义来模块化应用程序上下文文件 。 该概念非常适合使bean定义与定义和使用它们的模块保持一致。
也许这种理念非常适合用于足够小的Maven项目集的应用，一旦组织使用bean定义定义了一百个项目，此技巧就成为了控制的噩梦。 [让我们不要忘记现在的最新状态。]在许多相关的应用程序上下文中，结合魔法咒语，分层和大量Spring bean的委派，可能确实导致了Sam Atkinson的巨大认知负担。 但是，严格来讲，这不是Spring框架，而是“一切都是钉子”的应用。
最后，软件复杂性是许多企业的祸根，而构建足够大的应用程序然后不得不对其进行解密，精简下来并最终加以替换的后果可能会导致人们的冠冕堂皇 。 Java内最大的复杂性项目也许是Oracle和Sun Microsystems对JDK本身的模块化，并且完全不使用依赖项注入容器。 Atkinson谈到了Spring Boot作为围绕框架的框架可能带来的谬论，并且可能存在危险。 他的想法是正确的，因为Java EE还没有关于完全嵌入式应用程序服务器基础结构的标准API或JSR。 [Antonio Gonclaves和其他人，包括我自己，都呼吁将这样的API “一个容器来统治所有人”不止一次地出现。
如果您使用WildFly Swarm之类的产品走这条路，那将存在不确定的路径，因为您的工具链和开发机制可能不会一直支持您。 例如，您的IDE可能无法实现Hot JVM类的重新加载，或者不能对前端页面内容的更改做出很大贡献。 这些所谓的无容器解决方案依赖于已经模块化为单独组件的应用程序的概念。 如果您的应用程序是一个巨大的BEHEMOTH，那么将其转到嵌入式应用程序服务器应用程序中将无济于事。 相反，您需要认真的工作才能到达微服务阶梯的第一个梯级，例如尝试在您自己的组织中取消意大利面条项目和Maven依赖关系。 失败的原因是无法理解大规模的Spring Framework应用程序仅仅是疾病的症状，而不是诊断的症状。
我们为什么要输？ 也许是一个问题，为什么我们现在只是失去它？ 软件工程中最困难的问题是弄清楚如何使用LEGACY SOFTWARE和DREAMSCAPING。 大多数工程师对遗留软件和技术债务的概念有所了解。 编写无错误，灵活且敏捷的应用程序非常困难； 坚固且具有极高的可维护性。 大多数技术高级管理人员要么忘记了，要么不相信对遗产的影响。
然后，梦想着招聘公司，有时是公司业务向我们出售工程师，设计师和建筑师。 在九到一千万的Java开发人员中，大多数都是所谓的GREENFIELD的诱饵。 除非您从一开始就在一家初创公司工作，否则真的没有这种不起眼的绿色草坪。 即使现有企业催生了SKUNK工作团队，并承诺在几周或几个月内您不必与Legacy合作，您猜怎么着？
您将碰到新的带锁系统和旧版旧系统之间的集成。 萨姆·阿特金森（Sam Atkinson）对Spring框架感到沮丧的呼声的核心是应用程序的架构设计。 在企业现实世界中，绝大多数系统都是BROWNFIELD，请不要让招聘顾问哄骗您。 他本人说，由于该指令TIME-TO-MARKET较旧，他没有时间培训，指导和/或指导组织内的其他开发人员。 这个故事的寓意是，没有道德，只有我们处于运动技术领先的地位，击败Spring Framework，那又如何呢？
我们可以击败Java EE或PHP，Ruby和Scala。 如果我们无法控制自己的直觉，时间压力和设计，良好的旧人性将渗入我们的应用程序，并且我们可以尝试实现100％的代码覆盖率，并使用Cucumber，JBehave编写最佳的功能测试，我们仍然会失败未来几年的应用程序。 软件就是软件，我们大部分时间都在亏损，有时我们会赢。 在何时，何地以及如何实现这一宏伟目标非常困难。
翻译自: https://www.javacodegeeks.com/2015/12/whether-using-spring-framework-not-going-lose.html
353
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
