Spring 框架是非侵入性的。
你能详细说明一下吗？
谢谢你:)
【问题讨论】：
标签： java spring dependency-injection
在这里，“非侵入式”意味着您的应用程序代码不需要直接依赖于 Spring 框架。 任何可以注入适当依赖项的东西（理论上）都可以正常工作。
【讨论】：
非侵入式框架的主要吸引力在于它不会妨碍您的设计和建模活动。在您需要它之前，它会完全不碍事。
【讨论】：
完全可以在应用程序代码中使用 Spring 而不直接依赖于 Spring 框架。这并不意味着代码将在没有 spring 的情况下继续运行，因为 spring 提供的功能需要被另一个 IoC 容器或直接实例化依赖链中所有对象的代码替换，但这确实意味着您可以选择用弹簧或其他机制把东西连接起来。
但是，要真正不受 Spring 的干扰，您需要将所有配置保留在代码之外，这意味着对所有内容都使用 XML。这在春天工作得很好，但它对开发人员来说是一个痛苦，而且自从 Java 5 中广泛使用注释的出现以来，它并不是真正的 Java 方式。因此 Spring 提供了许多注释，用于直接在您的代码中将事物连接在一起。这显然可以在代码中创建对 Spring 的依赖关系，尽管所有 Spring 标记都在编译时解析，因此您仍然可以在 spring 上下文之外执行您的类，而无需依赖 spring jar 等。此外，只要有可能，自定义弹簧注释已被通用 JEE 注释替换。在 Spring 3 中，仅使用 JEE 注释和有限数量的 XML 来初始化应用程序上下文非常容易。
spring 做事方式的美妙之处在于，实现某个特性的底层功能通常可以在运行时选择。如果您在非托管容器中使用 ORM 系统进行开发，使用本机会话管理器，您可以轻松切换到生产环境中的容器托管会话，而无需更改任何代码，前提是您已将应用程序配置为让 spring 处理事务管理。标记为@Transactional 的方法将自动获取会话和事务，无论来源如何，无需对代码进行任何更改。事实上，如果你愿意的话，你可以轻松地切换到一个完全不同的 ORM 框架，尽管事实上这是一个非常罕见的用例，所以大多数应用程序倾向于在其数据访问中包含 ORM 框架特定的代码和/或查询代码。
spring 和老式的“侵入式”框架之间的区别在于，侵入式框架通常需要您实现特定的接口，或者更糟的是，为了访问框架功能，强制您从特定的基类继承。在后一种情况下，您不仅依赖于您正在使用的框架，而且还严重限制了您的类层次结构——在一种只允许单继承的语言中。 EJB 的最新版本从 Spring（和其他人的）较少干扰模型的优雅中学习，并且 EJB 本身已经变得更少干扰（这都是关于 POJO 的）。
我真的没有看到任何支持不知名的论点，即 Spring 现在是一个价值十亿美元的野兽，将用户锁定在其中。如果有的话，Spring 的侵入性比以往任何时候都小，同时提供了更多的功能。将自己锁定在 spring 中当然是有可能的，而且很多开发人员都非常愿意这样做，因为使用 spring 的运行时开销是如此之小，以至于我们大多数人都无法想象我们可能会删除的很多场景源于一个项目。如果我想要一个完全托管的 JEE 环境，我可以为此进行配置（并在任何可用供应商的容器中运行）。如果我想在 100% 来自 spring 的配置和运行时管理的情况下在 tomcat 或 jetty 中运行，我也可以这样做。因此，除非项目要求明确禁止，否则我通常非常乐意使用特定于弹簧的功能，但有锁定的风险。 Spring 在运行时增加的开销非常小，因此它是一个低风险的选择。
到了紧要关头，我发现 Spring 比 EJB 更容易学习。我可以用任何一种方法完成同样的事情，但如果我使用 Spring 与 EJB 相比，更容易引入没有经验的开发人员，因此招聘更容易，长期维护成本更低，发布周期更短。
【讨论】：
几年前，有一个非常“侵入性”的 EJB 野兽。 Spring 被吹捧为一组更简单的帮助类，它更像是库而不是框架。
今天，春天变成了新的野兽。作为一家价值 10 亿美元的企业，锁定人员符合他们的最大利益。是的，当然，您没有依赖问题，您可以随时退出 Spring。
使用 EJB，至少您有几个供应商可供选择。
【讨论】：