建设企业网站的流程,为什么想做网页设计师,网站开发案列,休闲农业有哪些网络营销方式在Twitter领域再次引起了一些反感 #xff0c;我看到了Sam Atkinson的博客帖子#xff0c;题为“ 为什么我讨厌Spring” 。 这篇博客文章的撰写早于2014年#xff0c;但是DZone后来才真正选择并发布了它。 实际上#xff0c;在撰写本文时#xff0c;Atkinson是一名开发人员… 在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 InjectionCDI1.0提供了强大的类型安全性。 对于成千上万采用Spring Framework的企业而言CDI为时已晚当时大多数企业都在努力从Java 1.4J2EE 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或PHPRuby和Scala。 如果我们无法控制自己的直觉时间压力和设计良好的老式人性将渗入我们的应用程序并且我们可以尝试实现100的代码覆盖率并使用CucumberJBehave编写最佳的功能测试我们仍然会失败未来几年的应用程序。 软件就是软件我们大部分时间都在亏损有时我们会赢。 在何时何地以及如何实现这一宏伟目标非常困难。 翻译自: https://www.javacodegeeks.com/2015/12/whether-using-spring-framework-not-going-lose.html
