再谈开源框架的“非侵入”还有意义吗？

    "非侵入“这词应该是spring最开始主打的口号吧，也唱响了新一代开源框架的发展潮流，君不见目前非常多的框架都在大谈自己是”非侵入“式的，程序员也在津津乐道”非侵入“式的好处，我个人认为，最开始”非侵入“背后的意义应该是框架的灵活切换，而不仅仅是代码中的”非侵入“，而如今，spring、struts等，虽然可以实现代码的”无侵入“，但背后的”已绑定“似乎已经违背了初衷。那再谈”非侵入“还有何意义？

评论

62 楼 di1984HIT 2014-01-03  

讨论的好激烈。

61 楼 belover 2009-09-05  

pipilu 写道

哎，真服了。你是为了证明你提的问题是合理的，还是为了探求答案？
赶快隐藏吧。

同意楼上！

很难想象。在 javaeye 这种深度交流的技术社区。还有这么没有任何实际意义的讨论！
楼主下课吧！

60 楼 pipilu 2009-09-04  

哎，真服了。你是为了证明你提的问题是合理的，还是为了探求答案？
赶快隐藏吧。

59 楼 herowzz 2009-09-04  

如果说到标准的话，spring本来就是反标准的。
再说，用标准就不被入侵了？现在有几个程序是用标准写的？标准还不都是那些厂商们你定一套，我定一套。使用ejb，jsf等等你就可以随意更换到别的框架吗？
如果照你那样理解入侵的话，那任何第三方框架都别使用了，直接jdbc，servlet最符合您的要求？

58 楼 qianhd 2009-09-04  

其实都是一场梦
随便一个需求的修改 都可以让框架侵入的体无完肤

57 楼 ferreousbox 2009-09-04  

随着大家的关注点和出发角度不同，问题就像wq163说的已经扩散了，往往有些朋友就抓住言论中的一些关键字来进行辩驳，所以难免会出现争执和意见不统一，这往往也是思想的碰撞。所以，我认为我们讨论的前提应该是基于一个共同的认识，那就是怎么界定“入侵”？

从狭义的角度讲，直接对框架代码的依赖，这是无可厚非被大家认同的直接入侵；

从广义的角度讲，只要你使用了就是被入侵了，当然这里还有一个度和界限的问题，这里的界限和度我理解为标准，即使用标准的东西是可以被认为非入侵的，因为是依赖标准而非具体实现。好比我们使用JDBC框架或OSGI框架，这是依赖标准。

而spring等提出的非入侵就像前面有朋友提到的是基于单元测试的易用性和非依赖性的这样一个维度，但是我也要说，在什么都可以MOCK的年代入侵不入侵真的还那么重要么？

另外，我的初衷并不是说因为入侵而不使用，而是说不要因为非入侵而刻意非入侵！

56 楼 delphixp 2009-09-04  

很多人对于“非侵入”这个概念的感知，都是来自那本《without EJB XXX》的吧？

就这本书来说说“非侵入”的含义：

  1）使用容器的同时，无须实现（继承）容器的任何接口（类）。相比于旧版的EJB，你必须要实现相应的接口。

  2）在进行测试时（例如TDD），可以使用灵活的测试方法。（例如用 JUNIT，或者一个main 方法）相比于旧版的EJB，每次测试都要花相当时间等待容器的停止/启动，要脱离容器来做测试的话，比较困难或麻烦。

应该说，这种“非侵入”性是相对于旧版的EJB而言。使用流行语来说就是，旧版的EJB容器是“重侵入”的，是一种卖身的关系。而对于 Spring 这种容器来说，是“轻侵入”的，是一种合作关系。

完全没有侵入性，是不存在的。只要你用框架，你就必须要遵守框架所制定的“游戏规则”。这种规则不是要求你调用/创建框架对象，就是要求你实现/继承框架接口/类，又或者某种特定的配置文件。不要认为只需要配置文件，就没侵入性，配置文件是“侵入”到系统，而不是代码而已。

所以，对于“非侵入”性的理解，更多是：尽量减少框架“入侵”到你的代码中去。要知道，错误、复杂度等都具有传递性，代码越是“纯洁”就意味着更少依赖性，更好的维护性。

55 楼 herowzz 2009-09-04  

wq163 写道

什么是入侵每个人都有自己的观点，
lz可能是说一旦用了spring就不可能脱离它了，接着后面又有人说可以切换其他容器来反驳，
然后又有人说没有切换的必要，……
问题扩散开了争论就多了，根据自己的尺度定义入侵就行啦，
各位好好定义一下入侵的范畴  继续发表高见，我撤了

“什么是入侵每个人都有自己的观点”
扯蛋，自己没弄明白什么是入侵就不要在这高谈阔论

54 楼 wq163 2009-09-03  

downpour 写道

wq163 写道

对于入侵定义的级别不同，以你的目标来定义入侵的范畴，那么你这样说是对的。
但是你不能限制别人也按照你的目标来定义入侵。单元测试不依赖其他jar不能说明就没有入侵，运行、集成测试时还是会依赖的。
这种东西争来争去其实没意思的，呵呵

集成测试你能不依赖容器？不依赖容器算集成测试吗？

所以讨论的首要条件就是定义入侵的范畴。你说说看，什么是入侵？

什么是入侵每个人都有自己的观点，
lz可能是说一旦用了spring就不可能脱离它了，接着后面又有人说可以切换其他容器来反驳，
然后又有人说没有切换的必要，……
问题扩散开了争论就多了，根据自己的尺度定义入侵就行啦，
各位好好定义一下入侵的范畴  继续发表高见，我撤了

53 楼 downpour 2009-09-03  

wq163 写道

对于入侵定义的级别不同，以你的目标来定义入侵的范畴，那么你这样说是对的。
但是你不能限制别人也按照你的目标来定义入侵。单元测试不依赖其他jar不能说明就没有入侵，运行、集成测试时还是会依赖的。
这种东西争来争去其实没意思的，呵呵

集成测试你能不依赖容器？不依赖容器算集成测试吗？

所以讨论的首要条件就是定义入侵的范畴。你说说看，什么是入侵？

52 楼 wq163 2009-09-03  

downpour 写道

wq163 写道

lz说得不是代码级别的入侵，怎么这么多人都不理解呢，就算没有引入任何spring的代码，也是有隐式入侵的。
一旦用了它的IOC其实就已经被绑架了。你的各种依赖关系都依靠它来管理，脱离不了spring了。
切换其他类似的IOC容器理论上或者小项目中可以，但在大规模项目中完全是不可能的，你不可能把那么多依赖关系再配置一遍

你告诉我，什么是隐式入侵？发表观点之前，先要弄清楚概念。

Service调用Dao，他们之间的依赖关系，是如何定义的？如果没有容器，没有Spring，你能分别吗？显然不能。因为他们之间的依赖关系是通过setter和getter方法维护的。这种维护方式，哪里入侵到什么容器了？相反的，如果其他的IoC容器，需要通过依赖它的代码来管理依赖关系，那才叫真正的入侵。

所以，所谓的入侵与不入侵，都是相对于容器本身的实现规则而定的。按照你的说法，在大规模项目中，我的确不可能吧那么多的依赖关系再配置一遍，所以我也不会去切换IoC容器，因为那没有必要。我们的目标是，让我们的业务逻辑代码，能够在不依赖于其他jar包的情况下能够方便的进行单元测试。这才是我们将代码写得不入侵的目的。

对于入侵定义的级别不同，以你的目标来定义入侵的范畴，那么你这样说是对的。
但是你不能限制别人也按照你的目标来定义入侵。单元测试不依赖其他jar不能说明就没有入侵，运行、集成测试时还是会依赖的。
这种东西争来争去其实没意思的，呵呵，我闪了

51 楼 downpour 2009-09-03  

wq163 写道

lz说得不是代码级别的入侵，怎么这么多人都不理解呢，就算没有引入任何spring的代码，也是有隐式入侵的。
一旦用了它的IOC其实就已经被绑架了。你的各种依赖关系都依靠它来管理，脱离不了spring了。
切换其他类似的IOC容器理论上或者小项目中可以，但在大规模项目中完全是不可能的，你不可能把那么多依赖关系再配置一遍

你告诉我，什么是隐式入侵？发表观点之前，先要弄清楚概念。

Service调用Dao，他们之间的依赖关系，是如何定义的？如果没有容器，没有Spring，你能分别吗？显然不能。因为他们之间的依赖关系是通过setter和getter方法维护的。这种维护方式，哪里入侵到什么容器了？相反的，如果其他的IoC容器，需要通过依赖它的代码来管理依赖关系，那才叫真正的入侵。

所以，所谓的入侵与不入侵，都是相对于容器本身的实现规则而定的。按照你的说法，在大规模项目中，我的确不可能吧那么多的依赖关系再配置一遍，所以我也不会去切换IoC容器，因为那没有必要。我们的目标是，让我们的业务逻辑代码，能够在不依赖于其他jar包的情况下能够方便的进行单元测试。这才是我们将代码写得不入侵的目的。

50 楼 wq163 2009-09-03  

daquan198163 写道

wq163 写道

iday 写道

ferreousbox 写道

我这里说到的“入侵”并不仅仅指业务层，一般也是建议业务层是不依赖任何框架和组件的，毕竟是系统的核心处理层。但还有其他各个层，如视图、控制等。我一开始也就阐明了一旦你一开始使用这类框架，就已经实际上被框架隐式入侵了。

前面有朋友提到实现和接口的绑定可以采用其他IOC容器，我想这位朋友根本就没有仔细想这类问题，这里已经不再是简单的IOC问题了，即使你举这样的例子也是不恰当的，你想，如果你使用spring的事务管理（举个例子），你想还有其他实现一样功能的框架来给你用么？这就是标准化于非标准化的问题！所以我的意思是在没有成为标准的前提下谈非入侵都是不必要的，即使是事实标准。而且你也不用刻意的在你的系统中避免导入代码依赖，因为你根本不可能再脱离这个框架了，这就是实质问题！！！

你一直在说什么隐式入侵，指的是代码的入侵么？你说的spring事务的例子，我用到现在都是用aop注入spring事务的，这应该不算是入侵了吧。是不是真的代码入侵，完全是看你的代码怎么写的，如果没有能力做到代码不入侵，那也就不要谈这个问题了。所以Rod Johnson能写出spring，而我们还在这里讨论spring到底侵入了没有。

lz说得不是代码级别的入侵，怎么这么多人都不理解呢，就算没有引入任何spring的代码，也是有隐式入侵的。
一旦用了它的IOC其实就已经被绑架了。你的各种依赖关系都依靠它来管理，脱离不了spring了。
切换其他类似的IOC容器理论上或者小项目中可以，但在大规模项目中完全是不可能的，你不可能把那么多依赖关系再配置一遍

这有什么，要是以后真出来一个新的ioc容器，兼容spring是完全有必要的，也是不难做到的，
wps还兼容office呢。
ps：看不出有什么必要去切换IoC容器。

看到前面有人说，不绑定在Spring上为什么不能使用其他的IoC实现，我是为了说明切换容器不是想象的那么简单。
至于说新的容器兼容spring，那就是另外一个话题了

49 楼 eric860 2009-09-03  

其实就是LZ在“非入侵”的理解上走极端了。

48 楼 daquan198163 2009-09-03  

wq163 写道

iday 写道

ferreousbox 写道

我这里说到的“入侵”并不仅仅指业务层，一般也是建议业务层是不依赖任何框架和组件的，毕竟是系统的核心处理层。但还有其他各个层，如视图、控制等。我一开始也就阐明了一旦你一开始使用这类框架，就已经实际上被框架隐式入侵了。

前面有朋友提到实现和接口的绑定可以采用其他IOC容器，我想这位朋友根本就没有仔细想这类问题，这里已经不再是简单的IOC问题了，即使你举这样的例子也是不恰当的，你想，如果你使用spring的事务管理（举个例子），你想还有其他实现一样功能的框架来给你用么？这就是标准化于非标准化的问题！所以我的意思是在没有成为标准的前提下谈非入侵都是不必要的，即使是事实标准。而且你也不用刻意的在你的系统中避免导入代码依赖，因为你根本不可能再脱离这个框架了，这就是实质问题！！！

你一直在说什么隐式入侵，指的是代码的入侵么？你说的spring事务的例子，我用到现在都是用aop注入spring事务的，这应该不算是入侵了吧。是不是真的代码入侵，完全是看你的代码怎么写的，如果没有能力做到代码不入侵，那也就不要谈这个问题了。所以Rod Johnson能写出spring，而我们还在这里讨论spring到底侵入了没有。

lz说得不是代码级别的入侵，怎么这么多人都不理解呢，就算没有引入任何spring的代码，也是有隐式入侵的。
一旦用了它的IOC其实就已经被绑架了。你的各种依赖关系都依靠它来管理，脱离不了spring了。
切换其他类似的IOC容器理论上或者小项目中可以，但在大规模项目中完全是不可能的，你不可能把那么多依赖关系再配置一遍

这有什么，要是以后真出来一个新的ioc容器，兼容spring是完全有必要的，也是不难做到的，
wps还兼容office呢。
ps：看不出有什么必要去切换IoC容器。

47 楼 wq163 2009-09-03  

iday 写道

ferreousbox 写道

我这里说到的“入侵”并不仅仅指业务层，一般也是建议业务层是不依赖任何框架和组件的，毕竟是系统的核心处理层。但还有其他各个层，如视图、控制等。我一开始也就阐明了一旦你一开始使用这类框架，就已经实际上被框架隐式入侵了。

前面有朋友提到实现和接口的绑定可以采用其他IOC容器，我想这位朋友根本就没有仔细想这类问题，这里已经不再是简单的IOC问题了，即使你举这样的例子也是不恰当的，你想，如果你使用spring的事务管理（举个例子），你想还有其他实现一样功能的框架来给你用么？这就是标准化于非标准化的问题！所以我的意思是在没有成为标准的前提下谈非入侵都是不必要的，即使是事实标准。而且你也不用刻意的在你的系统中避免导入代码依赖，因为你根本不可能再脱离这个框架了，这就是实质问题！！！

你一直在说什么隐式入侵，指的是代码的入侵么？你说的spring事务的例子，我用到现在都是用aop注入spring事务的，这应该不算是入侵了吧。是不是真的代码入侵，完全是看你的代码怎么写的，如果没有能力做到代码不入侵，那也就不要谈这个问题了。所以Rod Johnson能写出spring，而我们还在这里讨论spring到底侵入了没有。

lz说得不是代码级别的入侵，怎么这么多人都不理解呢，就算没有引入任何spring的代码，也是有隐式入侵的。
一旦用了它的IOC其实就已经被绑架了。你的各种依赖关系都依靠它来管理，脱离不了spring了。
切换其他类似的IOC容器理论上或者小项目中可以，但在大规模项目中完全是不可能的，你不可能把那么多依赖关系再配置一遍

46 楼 jnoee 2009-09-03  

怎么不拿Rails来说事呢？在应用的层面其实没有必要去考究这些，尽快的为客户提供软件价值是首要的目标。在一个成熟的应用框架面前，无所谓侵入不侵入，因为你更换框架的几率为0。如果你最终真的要更换这个框架，那只能说你最开始的选择就是错误的。IOC容器会使得这种错误付出的代价略微变小一点。

赞同solonote观点。
在未知面前才需要灵活，杞人忧天那是自寻烦恼。很多人还在为了接口而接口，为了虚无缥缈而灵活设计。在应用的层面上，一个DAO一个接口、一个service一个接口，理由还非常的冠冕堂皇，非常可悲。

45 楼 iday 2009-09-02  

ferreousbox 写道

我这里说到的“入侵”并不仅仅指业务层，一般也是建议业务层是不依赖任何框架和组件的，毕竟是系统的核心处理层。但还有其他各个层，如视图、控制等。我一开始也就阐明了一旦你一开始使用这类框架，就已经实际上被框架隐式入侵了。

前面有朋友提到实现和接口的绑定可以采用其他IOC容器，我想这位朋友根本就没有仔细想这类问题，这里已经不再是简单的IOC问题了，即使你举这样的例子也是不恰当的，你想，如果你使用spring的事务管理（举个例子），你想还有其他实现一样功能的框架来给你用么？这就是标准化于非标准化的问题！所以我的意思是在没有成为标准的前提下谈非入侵都是不必要的，即使是事实标准。而且你也不用刻意的在你的系统中避免导入代码依赖，因为你根本不可能再脱离这个框架了，这就是实质问题！！！

你一直在说什么隐式入侵，指的是代码的入侵么？你说的spring事务的例子，我用到现在都是用aop注入spring事务的，这应该不算是入侵了吧。是不是真的代码入侵，完全是看你的代码怎么写的，如果没有能力做到代码不入侵，那也就不要谈这个问题了。所以Rod Johnson能写出spring，而我们还在这里讨论spring到底侵入了没有。

44 楼 wisdomer 2009-09-02  

建议直接写二进制机器代码，这样就没有入侵了。

43 楼 Discry 2009-09-02  

fyting 写道

advantech 写道

Spring的代码难读那Linux核心的代码就是天书，我们是拿框架写应用的，不是做基础研究的，你的关注点应该是怎么为你的客户提供优质的产品。

看代码和做产品这两者没必然冲突啊，有吗？

楼主这个问题本身就没什么意义嘛