框架的侵入性问题是不是一个伪问题？

凡事当然不能走极端。必然不可能所有代码都是不依赖框架的。
但是比较在域代码级别的无处不在的依赖，配置文件的依赖难道不是好多了？

如果配置文件足够简单的话，那么移植的代价难道不是很小？

即使不移植，难道不能用spring框架作production，用pico,yan做某些单元测试？甚至重构的时候把某些本来是容器管理的对象拿到容器外自己管理？

感觉又回到当初诸如“假如要换数据库，那么，……，所以要持久层”，“假如要从Hibernate换到ibatis，应该怎么办”这样的讨论。好像没有人讨论过在rails里面替换掉activeRecord/activePack或者中间哪一个组件。同样，在java中基本上用hibernate的还在用hibernate，用oracle的还在用oracle。
所以还是支持robbin的有利于单元测试的观点。推广一步说，无约束性的框架应该有利于敏捷开发。

对于解决相同的问题，各个框架侵入性高低不同，当然倾向于选择低的。不以无侵入性为标准，因为spring,webwork这些框架可以只要求提供无参构造方法,因此它们可以宣称无侵入性;但一些UI框架就不可能了.对于复杂的问题,要看各个抽象层次上的侵入性如何.

我把侵入性理解为对框架代码的依赖。进一步的，我们的代码要被框架调用，我们要调用框架的代码。在侵入性的要求下，系统中的知道框架存在的代码越少越好，对其他部分的设计产生的影响越少越好。我的假设就是如果低侵入性不光是为了好测试，还是为了“易于替换框架”。那么也就是说，框架本身不能对自己要回调的对象有任何要求，这种要求可能是继承一个基类，实现一个接口，遵守一个命名规范，标注一个Annotation。并且我们在调用框架的时候，还要封装一层，已保证同样的功能可以用其他框架或者库或者任何形式的第三方代码来完成。所以我把侵入性理解成了这个样子，也许我树了一个不存在的靶子。我觉得有些框架在吹嘘自己的时候，对买家有这样的暗示，就是你用我也可以抛弃我。实际显然不是如此。
如果把“易于替换框架”做为一个框架API设计的考虑标准的话，就出现了代码上无侵入性，配置文件中有侵入性的现象。我不知道Hibernate的配置文件算不算一个例子，它保证了对象无需继承，没有静态增强。但是用配置文件和动态增强，一样是有侵入性的。我觉得使用了框架，根本没有换掉一说。设计框架API的时候，考虑的只有好不好用（用在产品代码中），好不好测试（用在测试代码中），而不存在框架是不是允许你的代码移植到别的框架的问题，因为这不可能，除非重写。[ / quote]

依赖一个框架没有什么不好的。只要它真的为你带来了“好处”！
框架迁移，基本不用考虑。
如果一个框架好用，为什么要迁移呢？
如果有一个迁移的理由，那么那个理由就有足够让你为此付出代价好处！

我还是很欣赏楼主提出这个疑问。有独立的思维。

对于侵入性，我以为，就是说使用某种方式的框架，对你代码有何特殊要求。
当然，对你的代码没有任何要求是最好的，意味着你可以不用改代码就迁入或迁出某框架。

但任何都的因素都不应单独的考虑。此消彼长，互相制约。总之还是要整体考量的。

我们的web service用axis，那叫一个别扭啊。大量的代码依赖axis，为了节省工作量，还有一个手写的ruby code generator来生成一些stub类给axis用。这个erb的代码还有若干的bug，和为了简化codegen的难度而定的若干要求：
所有的接口签名上的东西必须都用接口。比如你只需要一个Pair，不能写java bean，必须是IPair的接口。
接口必须叫做ISomething。
接口不能继承其他接口。

等等等等。


现在大家都受够了Axis了，想换。可是你从XFire转到别的框架容易。从Axis转走？不扒你一层皮才怪。

说到遗留系统，这也是一个没有侵入性的框架的用武之地。对代码没有任何需求，也就意味着任何代码（即使是恶心的遗留系统）都可以用这个框架。

框架的侵入性小，你自己代码的灵活性就高

并不是说侵入性小的目的就一定是要替换框架

侵入就是依赖吧，框架侵入就是代码对框架的依赖，spring的IOC就是做的非常好的一个例子，如果只是用IOC，纳spring不会侵入我们的代码，有的人说即使框架侵入我们的代码，我们照样能写出程序来，对，是这样的，这个问题好比就是用struts的人要换webwork2一样，它们完成的事情是一样的，为什么还要换它呢，原因再于人总是趋向去使用更好的东西，框架侵入代码可以比作使用struts，框架不侵入代码可以比作使用webwork2，让我们选择，我们会选拿一个呢？所以这个问题不单是软件上的问题，而实际上是说明了人们都有对美好东西的那种向往和追求。所以这个并不是一个伪问题，是一个实实在在的问题

据说struts最大的毛病是不利于单元测试。 说实话，有时候我宁可它没有那么优雅，宁可去继承去实现什么，以换来高性能。本人对反射充满了畏惧，呵呵。 至于说换框架，基本不可能的事情，至少我遇到的应用是如此。

我还是很支持robbin的观点。