框架所宣称的非侵入性是不是一个伪命题
Is the non-intrusive claimed by the framework a false proposition
不管是什么语言方向，总的来说，一个框架侵入性太强，这是一种批评的声音，所以我猜也不是因为这个，非侵入性成为了宣传的“卖点” .
例如spring和struts 2使用注解、配置文件、约定或反射（其他语言可能是其他方式）实现无侵入，编译运行不正式依赖框架 API.
但本质上，如果没有这个框架，我们的程序根本无法运行正确。这些所谓的注解是定制的。它们的处理时间和处理方式不同。想想从 gson 到 Jackson 的迁移。迁移有成本和风险。需要用户写一个新的吗？
另外，真正迁移的概率有多大？感觉很小
我觉得你的问题很有趣但是有点主观..
我的想法是，我们必须构建能够适应变化但又保持务实的应用程序。我们需要找到抽象和实现之间的好点（如 Clean Architecture 一书中所述）。
在 Java eco-system 中，标准 JSR 通常是围绕接口而不是实现定义的，这为您提供了避免与特定框架紧密耦合的好方法（例如：JPA 而不是休眠，JAX-RS 而不是 Jackson..).
在 Spring 生态系统中，您可以使用这些标准注释（@Inject 与 @Autowired），它会完美地工作，但您通常会失去实现提供的一些功能。
一些架构倾向于将业务代码和框架代码之间的层完全分开（the hexagonal architecture 称之为基础设施层和应用程序层），但这是有代价的..
此类迁移的可能性未知，取决于项目不断变化的需求（我从未遇到过 JPA 供应商实现的变化）。但是我相信，对于最活跃的项目（Hibernate，Jackson..），你可以尝试减少它。
所以...要务实:)
这个问题似乎是基于一个非常宽泛的定义 non-invasive。 “Non-invasive”对于我们这些从早期解决方案过渡到 DI 框架的人来说是非常具体的。这不是关于框架代码的编译时依赖性，也不是关于能够迁移到另一个框架（我们已经发现 EJB 供应商关于兼容性的承诺是有价值的）。我们面临的问题是如何编写能够测试业务逻辑的应用程序代码的单元测试，同时易于设置并能够快速 运行。
使用 EJB 的企业应用程序在 运行 测试方面面临巨大障碍。我们的应用程序充满了组件，如果不 运行 将它们放入 EJB 容器中就无法运行。测试很难设置，他们花了很长时间 运行，当测试失败时，更有可能是由于环境或配置问题，而不是被测试代码的问题。
Non-EJB 应用程序也不是很好，这些应用程序的常用架构普遍使用 Go4 单例模式，包括实现服务定位器。这些单例使用静态引用和类加载器来强制执行它们的 singleton-ness，并且没有很好的方法来模拟它们。有些地方使用测试的自定义配置来实现他们的单例，以避免测试触发不需要的行为，这意味着测试可以 运行 安全，但是实现单例需要做更多的工作，并且测试需要配置。
我对某些东西是否具有侵入性的实际测试是，我能否只为我想练习的功能编写单元测试，而不是陷入处理基础设施、配置或依赖性问题，而这些问题超出了我关心的直接领域是强加于我的吗？按照这个标准，Spring 就是 non-invasive。我可以轻松地编写测试来模拟他们的合作者，并仅使用我关心的逻辑。
这就是我根据自己的定义推理的方式。如果您想根据自己的想法提出自己的案例，我的建议是 1) 定义您的术语和 2) 根据您需要做的事情来测试某件事是否符合您的标准（越实用越好参数）。
不管是什么语言方向，总的来说，一个框架侵入性太强，这是一种批评的声音，所以我猜也不是因为这个，非侵入性成为了宣传的“卖点” .
例如spring和struts 2使用注解、配置文件、约定或反射（其他语言可能是其他方式）实现无侵入，编译运行不正式依赖框架 API.
但本质上，如果没有这个框架，我们的程序根本无法运行正确。这些所谓的注解是定制的。它们的处理时间和处理方式不同。想想从 gson 到 Jackson 的迁移。迁移有成本和风险。需要用户写一个新的吗？
另外，真正迁移的概率有多大？感觉很小
我觉得你的问题很有趣但是有点主观..
我的想法是，我们必须构建能够适应变化但又保持务实的应用程序。我们需要找到抽象和实现之间的好点（如 Clean Architecture 一书中所述）。
在 Java eco-system 中，标准 JSR 通常是围绕接口而不是实现定义的，这为您提供了避免与特定框架紧密耦合的好方法（例如：JPA 而不是休眠，JAX-RS 而不是 Jackson..).
在 Spring 生态系统中，您可以使用这些标准注释（@Inject 与 @Autowired），它会完美地工作，但您通常会失去实现提供的一些功能。
一些架构倾向于将业务代码和框架代码之间的层完全分开（the hexagonal architecture 称之为基础设施层和应用程序层），但这是有代价的..
此类迁移的可能性未知，取决于项目不断变化的需求（我从未遇到过 JPA 供应商实现的变化）。但是我相信，对于最活跃的项目（Hibernate，Jackson..），你可以尝试减少它。
所以...要务实:)
这个问题似乎是基于一个非常宽泛的定义 non-invasive。 “Non-invasive”对于我们这些从早期解决方案过渡到 DI 框架的人来说是非常具体的。这不是关于框架代码的编译时依赖性，也不是关于能够迁移到另一个框架（我们已经发现 EJB 供应商关于兼容性的承诺是有价值的）。我们面临的问题是如何编写能够测试业务逻辑的应用程序代码的单元测试，同时易于设置并能够快速 运行。
使用 EJB 的企业应用程序在 运行 测试方面面临巨大障碍。我们的应用程序充满了组件，如果不 运行 将它们放入 EJB 容器中就无法运行。测试很难设置，他们花了很长时间 运行，当测试失败时，更有可能是由于环境或配置问题，而不是被测试代码的问题。
Non-EJB 应用程序也不是很好，这些应用程序的常用架构普遍使用 Go4 单例模式，包括实现服务定位器。这些单例使用静态引用和类加载器来强制执行它们的 singleton-ness，并且没有很好的方法来模拟它们。有些地方使用测试的自定义配置来实现他们的单例，以避免测试触发不需要的行为，这意味着测试可以 运行 安全，但是实现单例需要做更多的工作，并且测试需要配置。
我对某些东西是否具有侵入性的实际测试是，我能否只为我想练习的功能编写单元测试，而不是陷入处理基础设施、配置或依赖性问题，而这些问题超出了我关心的直接领域是强加于我的吗？按照这个标准，Spring 就是 non-invasive。我可以轻松地编写测试来模拟他们的合作者，并仅使用我关心的逻辑。
这就是我根据自己的定义推理的方式。如果您想根据自己的想法提出自己的案例，我的建议是 1) 定义您的术语和 2) 根据您需要做的事情来测试某件事是否符合您的标准（越实用越好参数）。