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