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

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

评论

22 楼 herowzz 2009-09-01  

ferreousbox 写道

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

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

你说来说去怎么感觉你总说不到点上呢？
框架到底哪里侵入业务层了？说半天说不出个所以然来。
说不出来就拿代码举例，本来业务层是怎么写的？用了框架后又怎么写了？把框架去了又出现怎么问题了？

友情提示：你举spring例子是最错误的，spring的侵入性是最低的

21 楼 ferreousbox 2009-09-01  

downpour 写道

ferreousbox 写道

downpour 写道

spring所谈的非入侵的前提是通过IoC容器实现的对象生命周期的管理，从而使得你的程序可以不必依赖你的运行环境。从实现角度来说，spring的非入侵，是基于setter和getter方法的的JavaBean标准。

所以要谈非入侵，必须有一个角度。

诚然你说的spring的IOC意义我不可否认，但这种只是非显示的入侵，即我们通常说的代码的引入。而背后隐式的入侵也正是这些框架的强大，我现在想要说的是，从你开始使用spring的时候你的应用已经被绑定到了spring上，即使你的代码没有引入和使用spring的类。在某个框架的配置格式非标准化时，你还能够指望使用其他框架来实现这样的功能么？（不要跟我说简单的IOC注入自己实现）

而程序不依赖环境的设置可以说是JAVA中面向接口的一大体现，不是非入侵才可以的，即依赖接口不依赖实现。至于整合其他框架的功能则不能够简单的理解为非侵入式。只是认为IOC是接口与实现分离的一个好的实现而已！

因此，我认为从你的程序开始使用像spring、struts等框架时，就抛开所谓的“非侵入”思想吧

和你这种理论家讨论问题真是累人啊。

我写一个普通的Service实现，哪里绑定到Spring上了？既然不绑定在Spring上，我为什么不能使用其他的IoC实现来做我的对象生命周期管理？

我已经很明确的告诉了你：

引用

spring的非入侵，是基于setter和getter方法的的JavaBean标准。

所以，凡是基于setter和getter方法来实现IoC的，都能被我的程序无入侵的使用，甚至自己实现一个也无妨。这东西和所谓的接口、实现没什么很大关系，和使用什么框架更加没有关系。

说到现在，我依然不知道你想要说明什么，是说这些框架归根到底都是有入侵的嘛？我认为你的论据还不能支撑你的观点。

看我上面的回答，如果你的系统只是简单的实用SET和GET特性我也就不说什么了，确实有很多框架可以做类似的事情，但你能够想象所有IOC容器都是一样的配置？都是一样功能？不可能，你能够想象使用了spring后再去切换其他的类似框架么？我想你也不会而且也不可能，这就是我要说的问题所在！---隐式绑定！

20 楼 ferreousbox 2009-09-01  

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

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

19 楼 zozoh 2009-09-01  

你的代码里，没用到 Spring 的类，就是没有被 Spring 侵入的。
当然，整个工程里，总会有点代码用到 Spring 的。

非侵入，不如叫：“少侵入”

18 楼 downpour 2009-09-01  

badqiu 写道

首先我列的这个类本来就是spring.jar里面的DaoSupport.

我列出上面的代码的意思就是可以执行checkDaoConfig()这类操作.

我倒是比较怀疑你难道从不使用这些生命周期函数.
而不是要我列举例子!!!

如在spring容器中我们有一个MailEngineService.
在初始化时需要启动一个线程池.
而是系统dispose时,我们需要将这个线程池未执行完成的线程等待它执行完才能将整个应用undeploy.

你到底是否明白我们讨论的前提条件？什么是业务逻辑层？要谈入侵性，就必须建立在业务逻辑层这个层面来进行讨论，你给我列一个spring.jar里面的类，告诉我要依赖于Spring，这不是废话吗？这不是业务逻辑层，兄弟！

我可以很负责任的告诉你，我从不在我的业务逻辑层中使用生命周期函数，因为这是没有必要的，所以我举不出例子，我想你也同样举不出例子来，所以你的论点是对的，可惜和入侵性无关。

17 楼 whaosoft 2009-09-01  

advantech 写道

框架是用来做东西的，做不出好东西说啥都没用。

说的很实在啊

16 楼 eric860 2009-09-01  

"侵入了"又怎么样呢？
"非侵入"最好的办法就是不使用。

15 楼 jeu1 2009-09-01  

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

14 楼 daquan198163 2009-08-31  

占绝大多数的无状态服务组件不需要这种回调，
你举的MailEngineService的例子应该属于有状态的组件，类似还有连接池等

13 楼 badqiu 2009-08-31  

downpour 写道

badqiu 写道

当然，我一直使用这个接口。一般是在afterPropertiesSet()中检查bean属性是否设置正确及其它相关操作。
而在spring配置文件中使用如下这种我是不推荐使用的.

<bean class="com.company.test.UserDao" init-method="init"></bean>

既然spring已经有生命周期接口，统一使用接口能够更加统一。

其它应用场景：
Quartz服务的启动
spring本身的DaoSupport

public abstract class DaoSupport implements InitializingBean {

	public final void afterPropertiesSet() throws IllegalArgumentException, BeanInitializationException {
		checkDaoConfig();
		try {
			initDao();
		}
		catch (Exception ex) {
			throw new BeanInitializationException("Initialization of DAO failed", ex);
		}
	}

	protected abstract void checkDaoConfig() throws IllegalArgumentException;
	protected void initDao() throws Exception {
	}

}

你这东西是业务逻辑层的东西？这不就是一个Dao工具类嘛？我不明白这东西为什么要自己实现，即使是自己实现，也不能被划到业务逻辑层的范畴。你这个类，和Spring提供的各种各样的DaoSupport类是没有区别的，是应该被打包到spring.jar中去，成为framework或者辅助类来使用的。

我们所谈的入侵性讨论，要基于的是真正的业务逻辑层的代码，具体表现为XXService或者XXManager。

首先我列的这个类本来就是spring.jar里面的DaoSupport.

我列出上面的代码的意思就是可以执行checkDaoConfig()这类操作.

我倒是比较怀疑你难道从不使用这些生命周期函数.
而不是要我列举例子!!!

如在spring容器中我们有一个MailEngineService.
在初始化时需要启动一个线程池.
而是系统dispose时,我们需要将这个线程池未执行完成的线程等待它执行完才能将整个应用undeploy.

12 楼 downpour 2009-08-31  

badqiu 写道

当然，我一直使用这个接口。一般是在afterPropertiesSet()中检查bean属性是否设置正确及其它相关操作。
而在spring配置文件中使用如下这种我是不推荐使用的.

<bean class="com.company.test.UserDao" init-method="init"></bean>

既然spring已经有生命周期接口，统一使用接口能够更加统一。

其它应用场景：
Quartz服务的启动
spring本身的DaoSupport

public abstract class DaoSupport implements InitializingBean {

	public final void afterPropertiesSet() throws IllegalArgumentException, BeanInitializationException {
		checkDaoConfig();
		try {
			initDao();
		}
		catch (Exception ex) {
			throw new BeanInitializationException("Initialization of DAO failed", ex);
		}
	}

	protected abstract void checkDaoConfig() throws IllegalArgumentException;
	protected void initDao() throws Exception {
	}

}

你这东西是业务逻辑层的东西？这不就是一个Dao工具类嘛？我不明白这东西为什么要自己实现，即使是自己实现，也不能被划到业务逻辑层的范畴。你这个类，和Spring提供的各种各样的DaoSupport类是没有区别的，是应该被打包到spring.jar中去，成为framework或者辅助类来使用的。

我们所谈的入侵性讨论，要基于的是真正的业务逻辑层的代码，具体表现为XXService或者XXManager。

11 楼 advantech 2009-08-31  

框架是用来做东西的，做不出好东西说啥都没用。

10 楼 mesmes 2009-08-31  

如果可移植性事关重大，那么就采用初始化方法，否则建议采用InitializingBean接口以减少应用程序所需的配置数量。
Pro Spring说的
As you can see, there is no difference in the output of the two examples; both work in exactly the same way. As we discussed earlier, both approaches have their benefits and drawbacks. Using an initialization method, you have the benefit of keeping your application decoupled from Spring, but you have to remember to configure the initialization method for every bean that needs it. Using InitializingBean, you have the benefit of being able to specify the initialization callback once for all instances of your bean class, but you have to couple your application to do so. In the end, you should let the requirements of your application drive the decision about which approach to use. If portability is an issue, then use the initialization method, otherwise use the InitializingBean interface to reduce the amount of configuration your application needs and the chance of errors creeping into your application due to misconfiguration.

9 楼 gordianyuan 2009-08-31  

badqiu 写道

当然，我一直使用这个接口。一般是在afterPropertiesSet()中检查bean属性是否设置正确及其它相关操作。
而在spring配置文件中使用如下这种我是不推荐使用的.

<bean class="com.company.test.UserDao" init-method="init"></bean>

既然spring已经有生命周期接口，统一使用接口能够更加统一。

恰恰相反, Spring建议的是使用init-method方法而非自身的生命周期接口.

8 楼 pipilu 2009-08-31  

<div class="quote_title">ferreousbox 写道</div>
<div class="quote_div">
<p>    "非侵入“这词应该是spring最开始主打的口号吧，也唱响了新一代开源框架的发展潮流，君不见目前非常多的框架都在大谈自己是”非侵入“式的，程序员也在津津乐道”非侵入“式的好处，我个人认为，<strong>最开始”非侵入“背后的意义应该是框架的灵活切换，而不仅仅是代码中的”非侵入“</strong>，而如今，spring、struts等，虽然可以实现代码的”无侵入“，但背后的”已绑定“似乎已经违背了初衷。那再谈”非侵入“还有何意义？</p>
</div>
<p>框架还要灵活切换呢？框架啊，哥们儿，你要怎么个灵活切换法？</p>
<p>容器，你可以灵活的从tomcat切换到WebLogic上。框架，你还打算搞点儿切换呢？</p>

7 楼 badqiu 2009-08-31  

downpour 写道

badqiu 写道

大概你不使用spring的生命周期接口？ 如果使用afterPropertiesSet()这<script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/themes/advanced/langs/zh.js"></script><script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/plugins/javaeye/langs/zh.js"></script>些，那是肯定依赖于spring的。而不都是简单的setter and getter.

当然现在的annotation, @Pre,@Post这些大部分IoC容器都支持，但如果我选择的spring的话，我是不会再去考虑切换IoC容器的，所以依赖于spring的接口也未尝不可。

我觉得最终的讨论，应该是大家到底相不相信spring,如果相信,依赖于spring可以省掉很多事.

朋友，你会在你系统的业务逻辑层代码中使用spring的Initialize接口？请给我一个实际的业务场景。

这完全不是相信不相信的问题，而是一个哲学问题。

当然，我一直使用这个接口。一般是在afterPropertiesSet()中检查bean属性是否设置正确及其它相关操作。
而在spring配置文件中使用如下这种我是不推荐使用的.

<bean class="com.company.test.UserDao" init-method="init"></bean>

既然spring已经有生命周期接口，统一使用接口能够更加统一。

其它应用场景：
Quartz服务的启动
spring本身的DaoSupport

public abstract class DaoSupport implements InitializingBean {

	public final void afterPropertiesSet() throws IllegalArgumentException, BeanInitializationException {
		checkDaoConfig();
		try {
			initDao();
		}
		catch (Exception ex) {
			throw new BeanInitializationException("Initialization of DAO failed", ex);
		}
	}

	protected abstract void checkDaoConfig() throws IllegalArgumentException;
	protected void initDao() throws Exception {
	}

}

6 楼 downpour 2009-08-31  

badqiu 写道

大概你不使用spring的生命周期接口？ 如果使用afterPropertiesSet()这些，那是肯定依赖于spring的。而不都是简单的setter and getter.

当然现在的annotation, @Pre,@Post这些大部分IoC容器都支持，但如果我选择的spring的话，我是不会再去考虑切换IoC容器的，所以依赖于spring的接口也未尝不可。

我觉得最终的讨论，应该是大家到底相不相信spring,如果相信,依赖于spring可以省掉很多事.

朋友，你会在你系统的业务逻辑层代码中使用spring的Initialize接口？请给我一个实际的业务场景。

这完全不是相信不相信的问题，而是一个哲学问题。

5 楼 badqiu 2009-08-31  

downpour 写道

ferreousbox 写道

downpour 写道

spring所谈的非入侵的前提是通过IoC容器实现的对象生命周期的管理，从而使得你的程序可以不必依赖你的运行环境。从实现角度来说，spring的非入侵，是基于setter和getter方法的的JavaBean标准。

所以要谈非入侵，必须有一个角度。

诚然你说的spring的IOC意义我不可否认，但这种只是非显示的入侵，即我们通常说的代码的引入。而背后隐式的入侵也正是这些框架的强大，我现在想要说的是，从你开始使用spring的时候你的应用已经被绑定到了spring上，即使你的代码没有引入和使用spring的类。在某个框架的配置格式非标准化时，你还能够指望使用其他框架来实现这样的功能么？（不要跟我说简单的IOC注入自己实现）

而程序不依赖环境的设置可以说是JAVA中面向接口的一大体现，不是非入侵才可以的，即依赖接口不依赖实现。至于整合其他框架的功能则不能够简单的理解为非侵入式。只是认为IOC是接口与实现分离的一个好的实现而已！

因此，我认为从你的程序开始使用像spring、struts等框架时，就抛开所谓的“非侵入”思想吧

和你这种理论家讨论问题真是累人啊。

我写一个普通的Service实现，哪里绑定到Spring上了？既然不绑定在Spring上，我为什么不能使用其他的IoC实现来做我的对象生命周期管理？

我已经很明确的告诉了你：

引用

spring的非入侵，是基于setter和getter方法的的JavaBean标准。

所以，凡是基于setter和getter方法来实现IoC的，都能被我的程序无入侵的使用，甚至自己实现一个也无妨。这东西和所谓的接口、实现没什么很大关系，和使用什么框架更加没有关系。

说到现在，我依然不知道你想要说明什么，是说这些框架归根到底都是有入侵的嘛？我认为你的论据还不能支撑你的观点。

大概你不使用spring的生命周期接口？ 如果使用afterPropertiesSet()这些，那是肯定依赖于spring的。而不都是简单的setter and getter.

当然现在的annotation, @Pre,@Post这些大部分IoC容器都支持，但如果我选择的spring的话，我是不会再去考虑切换IoC容器的，所以依赖于spring的接口也未尝不可。

我觉得最终的讨论，应该是大家到底相不相信spring,如果相信,依赖于spring可以省掉很多事.

4 楼 downpour 2009-08-31  

ferreousbox 写道

downpour 写道

spring所谈的非入侵的前提是通过IoC容器实现的对象生命周期的管理，从而使得你的程序可以不必依赖你的运行环境。从实现角度来说，spring的非入侵，是基于setter和getter方法的的JavaBean标准。

所以要谈非入侵，必须有一个角度。

诚然你说的spring的IOC意义我不可否认，但这种只是非显示的入侵，即我们通常说的代码的引入。而背后隐式的入侵也正是这些框架的强大，我现在想要说的是，从你开始使用spring的时候你的应用已经被绑定到了spring上，即使你的代码没有引入和使用spring的类。在某个框架的配置格式非标准化时，你还能够指望使用其他框架来实现这样的功能么？（不要跟我说简单的IOC注入自己实现）

而程序不依赖环境的设置可以说是JAVA中面向接口的一大体现，不是非入侵才可以的，即依赖接口不依赖实现。至于整合其他框架的功能则不能够简单的理解为非侵入式。只是认为IOC是接口与实现分离的一个好的实现而已！

因此，我认为从你的程序开始使用像spring、struts等框架时，就抛开所谓的“非侵入”思想吧

和你这种理论家讨论问题真是累人啊。

我写一个普通的Service实现，哪里绑定到Spring上了？既然不绑定在Spring上，我为什么不能使用其他的IoC实现来做我的对象生命周期管理？

我已经很明确的告诉了你：

引用

spring的非入侵，是基于setter和getter方法的的JavaBean标准。

所以，凡是基于setter和getter方法来实现IoC的，都能被我的程序无入侵的使用，甚至自己实现一个也无妨。这东西和所谓的接口、实现没什么很大关系，和使用什么框架更加没有关系。

说到现在，我依然不知道你想要说明什么，是说这些框架归根到底都是有入侵的嘛？我认为你的论据还不能支撑你的观点。

3 楼 ferreousbox 2009-08-31  

downpour 写道

spring所谈的非入侵的前提是通过IoC容器实现的对象生命周期的管理，从而使得你的程序可以不必依赖你的运行环境。从实现角度来说，spring的非入侵，是基于setter和getter方法的的JavaBean标准。

所以要谈非入侵，必须有一个角度。

诚然你说的spring的IOC意义我不可否认，但这种只是非显示的入侵，即我们通常说的代码的引入。而背后隐式的入侵也正是这些框架的强大，我现在想要说的是，从你开始使用spring的时候你的应用已经被绑定到了spring上，即使你的代码没有引入和使用spring的类。在某个框架的配置格式非标准化时，你还能够指望使用其他框架来实现这样的功能么？（不要跟我说简单的IOC注入自己实现）

而程序不依赖环境的设置可以说是JAVA中面向接口的一大体现，不是非入侵才可以的，即依赖接口不依赖实现。至于整合其他框架的功能则不能够简单的理解为非侵入式。只是认为IOC是接口与实现分离的一个好的实现而已！

因此，我认为从你的程序开始使用像spring、struts等框架时，就抛开所谓的“非侵入”思想吧