框架所宣称的非侵入性是不是一个伪命题

Question

不管是什么语言方向，总的来说，一个框架侵入性太强，这是一种批评的声音，所以我猜想也不是因为这个，非侵入性才成为宣传的“卖点”。

比如spring和struts 2使用注解、配置文件、约定或者反射（其他语言可能是其他方式）实现无侵入，编译运行对框架API没有正式依赖。

但本质上，如果没有这个框架，我们的程序根本无法正确运行。 这些所谓的注解是定制的。 它们的处理时间和处理方式不同。 想想从 gson 到 Jackson 的迁移。迁移有成本和风险。 你需要用户写一个新的吗？

另外，真正迁移的概率有多高？ 感觉很小。

Answer 1

这个问题似乎是基于对非侵入性意味着什么的非常广泛的定义。 “非侵入性”对于我们这些从早期解决方案过渡到 DI 框架的人来说意味着非常具体的东西。 这不是关于框架代码的编译时依赖性，也不是关于能够迁移到另一个框架（我们已经发现 EJB 供应商关于兼容性的承诺是有价值的）。 我们面临的问题是如何编写应用程序代码的单元测试，这些代码可以测试业务逻辑，同时易于设置并能够快速运行。

使用 EJB 的企业应用程序在运行测试时面临着巨大的障碍。 我们的应用程序充满了组件，如果不在 EJB 容器中运行它们就无法运行。 测试很难设置，它们需要很长时间才能运行，而且当测试失败时，更有可能是由于环境或配置问题，而不是被测试代码的问题。

非 EJB 应用程序也不是很好，这些应用程序的常用架构普遍使用 Go4 Singleton 模式，包括实现服务定位器。 这些单例使用 static 引用和类加载器来强制执行它们的单例性，并且没有很好的方法来模拟它们。 有些地方使用自定义测试配置来实现他们的单例，以避免测试触发不需要的行为，这意味着测试可以安全运行，但是实现单例需要做更多的工作，并且测试需要配置。

我对某些东西是否具有侵入性的实际测试是，我能否只为我想练习的功能编写单元测试，而不是陷入处理基础设施、配置或依赖性问题，这些问题超出了我的直接领域在乎是不是把自己强加于我？ 按照该标准，Spring 是非侵入性的。 我可以轻松地编写测试来模拟他们的合作者，并只执行我关心的逻辑。

这就是我根据自己的定义进行推理的方式。 如果您想根据自己的想法提出自己的案例，我的建议是 1) 定义您的术语和 2) 根据您需要做的事情来测试某件事是否符合您的标准（越实用越好争论）。

Answer 2

我认为你的问题很有趣，但有点主观..

我的想法是，我们必须构建对变化具有鲁棒性但仍保持务实的应用程序。 我们需要找到抽象和实现之间的好点（如 Clean Architecture 书中所述）。

在 Java 生态系统中，标准的 JSR 通常是围绕接口而不是实现来定义的，为您提供了一种避免与特定框架紧密耦合的好方法（例如：JPA 代替 Hibernate，JAX-RS 代替 Jackson..） .

在 Spring 生态系统中，您可以使用这些标准注解（@Inject 与 @Autowired），它会完美运行，但您通常会丢失实现提供的一些功能。

一些架构倾向于将业务代码和框架代码之间的层完全分开（六边形架构将其称为基础架构和应用程序层），但这是有代价的。

这种迁移的可能性是未知的，取决于您项目不断变化的需求（我从未遇到过 JPA 供应商实现的变化）。 但我相信对于最活跃的项目（Hibernate、Jackson..），您可以尝试减少它。

所以...务实:)