|
锁定老帖子 主题：再谈开源框架的“非侵入”还有意义吗？
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-08-31
"非侵入“这词应该是spring最开始主打的口号吧，也唱响了新一代开源框架的发展潮流，君不见目前非常多的框架都在大谈自己是”非侵入“式的，程序员也在津津乐道”非侵入“式的好处，我个人认为，最开始”非侵入“背后的意义应该是框架的灵活切换，而不仅仅是代码中的”非侵入“，而如今，spring、struts等，虽然可以实现代码的”无侵入“，但背后的”已绑定“似乎已经违背了初衷。那再谈”非侵入“还有何意义？ 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2009-08-31
spring所谈的非入侵的前提是通过IoC容器实现的对象生命周期的管理，从而使得你的程序可以不必依赖你的运行环境。从实现角度来说，spring的非入侵，是基于setter和getter方法的的JavaBean标准。
所以要谈非入侵，必须有一个角度。 |
| 返回顶楼 | |
|
发表时间：2009-08-31
而且也要看什么类型的框架，
比如Spring，它的不同部分也不一样，作为Ioc容器时它是非侵入的， 但是，作为MVC框架、单元测试框架、JDBC框架、ORM适配器时，它也做不到不侵入，事实上也没必要做到。 所以说，仅仅看到Spring Ioc非侵入就简单的以此为标准去要求所有类型的框架都达标是不合适的。 |
| 返回顶楼 | |
|
发表时间：2009-08-31
downpour 写道 spring所谈的非入侵的前提是通过IoC容器实现的对象生命周期的管理，从而使得你的程序可以不必依赖你的运行环境。从实现角度来说，spring的非入侵，是基于setter和getter方法的的JavaBean标准。
所以要谈非入侵，必须有一个角度。 诚然你说的spring的IOC意义我不可否认，但这种只是非显示的入侵，即我们通常说的代码的引入。而背后隐式的入侵也正是这些框架的强大，我现在想要说的是，从你开始使用spring的时候你的应用已经被绑定到了spring上，即使你的代码没有引入和使用spring的类。在某个框架的配置格式非标准化时，你还能够指望使用其他框架来实现这样的功能么？（不要跟我说简单的IOC注入自己实现） 而程序不依赖环境的设置可以说是JAVA中面向接口的一大体现，不是非入侵才可以的，即依赖接口不依赖实现。至于整合其他框架的功能则不能够简单的理解为非侵入式。只是认为IOC是接口与实现分离的一个好的实现而已！ 因此，我认为从你的程序开始使用像spring、struts等框架时，就抛开所谓的“非侵入”思想吧 |
| 返回顶楼 | |
|
发表时间：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的，都能被我的程序无入侵的使用，甚至自己实现一个也无妨。这东西和所谓的接口、实现没什么很大关系，和使用什么框架更加没有关系。 说到现在，我依然不知道你想要说明什么，是说这些框架归根到底都是有入侵的嘛？我认为你的论据还不能支撑你的观点。 |
| 返回顶楼 | |
|
发表时间：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可以省掉很多事. |
| 返回顶楼 | |
|
发表时间：2009-08-31
badqiu 写道 大概你不使用spring的生命周期接口？ 如果使用afterPropertiesSet()这些，那是肯定依赖于spring的。而不都是简单的setter and getter. 当然现在的annotation, @Pre,@Post这些大部分IoC容器都支持，但如果我选择的spring的话，我是不会再去考虑切换IoC容器的，所以依赖于spring的接口也未尝不可。 我觉得最终的讨论，应该是大家到底相不相信spring,如果相信,依赖于spring可以省掉很多事. 朋友，你会在你系统的业务逻辑层代码中使用spring的Initialize接口？请给我一个实际的业务场景。 这完全不是相信不相信的问题，而是一个哲学问题。 |
| 返回顶楼 | |
|
发表时间：2009-08-31
最后修改：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 {
}
}
|
| 返回顶楼 | |
|
发表时间：2009-08-31
最后修改：2009-08-31
ferreousbox 写道
"非侵入“这词应该是spring最开始主打的口号吧，也唱响了新一代开源框架的发展潮流，君不见目前非常多的框架都在大谈自己是”非侵入“式的，程序员也在津津乐道”非侵入“式的好处，我个人认为，最开始”非侵入“背后的意义应该是框架的灵活切换，而不仅仅是代码中的”非侵入“，而如今，spring、struts等，虽然可以实现代码的”无侵入“，但背后的”已绑定“似乎已经违背了初衷。那再谈”非侵入“还有何意义？ 框架还要灵活切换呢？框架啊，哥们儿，你要怎么个灵活切换法？ 容器，你可以灵活的从tomcat切换到WebLogic上。框架，你还打算搞点儿切换呢？ |
| 返回顶楼 | |
|
发表时间：2009-08-31
badqiu 写道 当然，我一直使用这个接口。一般是在afterPropertiesSet()中检查bean属性是否设置正确及其它相关操作。 而在spring配置文件中使用如下这种我是不推荐使用的. <bean class="com.company.test.UserDao" init-method="init"></bean> 既然spring已经有生命周期接口，统一使用接口能够更加统一。 恰恰相反, Spring建议的是使用init-method方法而非自身的生命周期接口. |
| 返回顶楼 | |
