|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2008-03-18
实际上我始终也搞不明白为什么需要PreDestroy和PostConstruct。
PreDestory还好理解一点，不过这个需要ioc容器来处理的么？Guice本身是无状态的，本来就没有这个事件。为什么不能在别的地方解决？比如你用servlet的话，servlet容器定义了destroy()事件，在destroy()里面做好了。 PostConstruct就更费解了，为什么有些东西你非要在construct之后执行呢？难道它不属于构建一个有效对象的一部分吗？PostConstruct事件之前你构建的是什么？一个早产儿？ |
| 返回顶楼 | |
|
最后更新时间：2008-03-19
为什么都喜欢拿Guice和Spring比较呢, 2者有可比性吗? Guice只是一个轻量级的IoC框架, Spring是为了对抗臃肿的J2EE的一个轻量级的企业开发框架, 关注的不仅仅 是IoC,而是在IoC基础上的一个企业级开发框架. 这样2者的关注度不一样, 如何比较. 做企业级开发你考虑用Guice? 要是需要一个轻量级的IoC容器, 才考虑用Guice.
|
| 返回顶楼 | |
|
最后更新时间：2008-03-19
skydream 写道 Guice不是08年的jolt framework的大奖吗？
楼主说它是玩具，呵呵，太过了。你写个玩具出来试试。 我承认我对Guice不了解，但是毕竟是google出的东西，好评不断，jolt也给了很高的评价。楼主不喜欢就算了，写这么个标题，只能说明你的心胸不够宽广，太不能接受不同意见了。 目前的guice本来就是玩具。即使它有很好的发展前景（实际上我也很看好它的将来），但是在目前，guice还无法使用在企业应用开发领域起到骨干的作用。在这个领域它还只是一个架子，一个粗略的架子，还有太多的东西需要补充。在guice提供这些支撑企业应用开发的功能之前，它就是个玩具。 不能因为你看好它，就无视它的缺点。 skydream不能接收别人的不同意见，说明你的心胸不够宽广。 我也很看好它的发展前景，很喜欢它的精巧，它的优雅。但是实际的开发是很现实的。你不能提供必要的功能，给程序员必要的帮助，那么再优雅也无用。我们都在期待着更多的人去完善它，充实它。等到那个时候，它才真的有了和spring一争高低的能力。 |
| 返回顶楼 | |
|
最后更新时间：2008-03-19
ajoo 写道 实际上我始终也搞不明白为什么需要PreDestroy和PostConstruct。
PreDestory还好理解一点，不过这个需要ioc容器来处理的么？Guice本身是无状态的，本来就没有这个事件。为什么不能在别的地方解决？比如你用servlet的话，servlet容器定义了destroy()事件，在destroy()里面做好了。 PostConstruct就更费解了，为什么有些东西你非要在construct之后执行呢？难道它不属于构建一个有效对象的一部分吗？PostConstruct事件之前你构建的是什么？一个早产儿？ 首先不是每个对象都是像servlet一样托管在类似servlet容器里面,其次既然我给你托管,那我的生命周期管理就是你的职责,为什么要在别的地方解决?ajoo大牛好像不是很喜欢有状态的,但既然叫容器肯定会有状态的 拿spring里面最常用的一个配置来说,如果你不用PreDestroy,难道要手动去关闭数据源?
<bean id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"
p:url="${jdbc.url}" p:username="${jdbc.username}"
p:password="${jdbc.password}"
p:driverClassName="${jdbc.driverClassName}"
p:poolPreparedStatements="true" />
用getter/setter方式注入时,就得用PostConstruct,getter/setter方式注入的好处我在另一个帖子有说过,再说了ajoo大牛一直在提无入侵式,如果强迫用构造参数注入就是入侵,况且很多公用的lib都是提供getter/setter. |
| 返回顶楼 | |
|
最后更新时间：2008-03-19
quaff 写道 拿spring里面最常用的一个配置来说,如果你不用PreDestroy,难道要手动去关闭数据源?
<bean id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"
p:url="${jdbc.url}" p:username="${jdbc.username}"
p:password="${jdbc.password}"
p:driverClassName="${jdbc.driverClassName}"
p:poolPreparedStatements="true" />
用getter/setter方式注入时,就得用PostConstruct,getter/setter方式注入的好处我在另一个帖子有说过,再说了ajoo大牛一直在提无入侵式,如果强迫用构造参数注入就是入侵,况且很多公用的lib都是提供getter/setter. 为什么要关闭数据源？ 如果多个app共用一个数据源，其中一个居然把DS干掉了，其他app怎么活。 |
| 返回顶楼 | |
|
最后更新时间：2008-03-19
引用 首先不是每个对象都是像servlet一样托管在类似servlet容器里面,其次既然我给你托管,那我的生命周期管理就是你的职责,为什么要在别的地方解决?ajoo大牛好像不是很喜欢有状态的,但既然叫容器肯定会有状态的 关键不是哪个容器托管的问题，而是谁定义了这个"destroy"事件。比如servlet容器定义了destroy事件，就应该servlet容器来管理在这个事件触发相应的生命周期。 另外，我不同意容器就肯定有状态。还是那句话，状态不可怕，可怕的是状态变化，是副作用。 quaff 写道 拿spring里面最常用的一个配置来说,如果你不用PreDestroy,难道要手动去关闭数据源?
<bean id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"
p:url="${jdbc.url}" p:username="${jdbc.username}"
p:password="${jdbc.password}"
p:driverClassName="${jdbc.driverClassName}"
p:poolPreparedStatements="true" />
那么这个destroy-method什么时候调用的呢？应用程序运行的时候肯定不行吧？是在系统关闭的时候？我也承认这个有用，Guice现在不支持优点缺陷。但是我怎么感觉用处不大？我们一般关注的是程序运行期间的事情，至于程序死后，你管它洪水滔天？ 
引用 用getter/setter方式注入时,就得用PostConstruct,getter/setter方式注入的好处我在另一个帖子有说过,再说了ajoo大牛一直在提无入侵式,如果强迫用构造参数注入就是入侵,况且很多公用的lib都是提供getter/setter. getter/setter也不见得需要某个特殊事件吧？比如：
@Provide
public Foo foo(A a, B b, C c) {
Foo foo = new Foo();
foo.setA(a);
foo.setB(b);
foo.setC(c);
foo.initialize();
return foo;
}
|
| 返回顶楼 | |
|
最后更新时间：2008-03-19
ajoo 写道 关键不是哪个容器托管的问题，而是谁定义了这个"destroy"事件。比如servlet容器定义了destroy事件，就应该servlet容器来管理在这个事件触发相应的生命周期。 这就是分歧,因为我认为destroy是最基本的事件不需要定义,不然怎么会成为jsr标准. ajoo 写道 另外，我不同意容器就肯定有状态。还是那句话，状态不可怕，可怕的是状态变化，是副作用。 你不把状态保存在容器里面就得保存在其他地方,但是放容器里面管理最好,状态变化的处理确实棘手,但跟放不放在容器里面没关系. ajoo 写道 那么这个destroy-method什么时候调用的呢？应用程序运行的时候肯定不行吧？是在系统关闭的时候？我也承认这个有用，Guice现在不支持优点缺陷。但是我怎么感觉用处不大？我们一般关注的是程序运行期间的事情，至于程序死后，你管它洪水滔天？
在容器关闭的时候调用,程序退出之前先关闭容器做好收尾工作. ajoo 写道 getter/setter也不见得需要某个特殊事件吧？比如：
@Provide
public Foo foo(A a, B b, C c) {
Foo foo = new Foo();
foo.setA(a);
foo.setB(b);
foo.setC(c);
foo.initialize();
return foo;
}
这个就是习惯问题,你觉着这样做更优雅但是我觉得这样做很丑陋,你这个其实就是构造参数注入,但是我相信大多数人都喜欢用java bean的getter/setter方式注入,再一次说一下这样做的优点 1.标准化,IDE都可以自动生成代码 2.可以手动重新注入 getter/setter的缺点除了让java代码多了一些之外我还没发现其他的 |
| 返回顶楼 | |
|
最后更新时间：2008-03-19
不知道大家说guice有前景是不是因为它还没什么功能。。。
感觉guice根本就没用，要我引入guice，不如自己写工厂算了，因为它提供的东西也没别的了 |
| 返回顶楼 | |
|
最后更新时间：2008-03-19
quaff 写道
@Provide
public Foo foo(A a, B b, C c) {
Foo foo = new Foo();
foo.setA(a);
foo.setB(b);
foo.setC(c);
foo.initialize();
return foo;
}
这个就是习惯问题,你觉着这样做更优雅但是我觉得这样做很丑陋,你这个其实就是构造参数注入,但是我相信大多数人都喜欢用java bean的getter/setter方式注入,再一次说一下这样做的优点 1.标准化,IDE都可以自动生成代码 2.可以手动重新注入 getter/setter的缺点除了让java代码多了一些之外我还没发现其他的 有点糊涂了。这个怎么会是构造注入呢？难道不是setter？这个@Provide是Guice module里面的东西，相当于你的Spring manual wiring的<bean>。只不过，你可以方便地做post-construct，不需要容器提供任何特殊的支持。 |
| 返回顶楼 | |
|
最后更新时间：2008-03-19
ajoo 写道 quaff 写道
@Provide
public Foo foo(A a, B b, C c) {
Foo foo = new Foo();
foo.setA(a);
foo.setB(b);
foo.setC(c);
foo.initialize();
return foo;
}
这个就是习惯问题,你觉着这样做更优雅但是我觉得这样做很丑陋,你这个其实就是构造参数注入,但是我相信大多数人都喜欢用java bean的getter/setter方式注入,再一次说一下这样做的优点 1.标准化,IDE都可以自动生成代码 2.可以手动重新注入 getter/setter的缺点除了让java代码多了一些之外我还没发现其他的 有点糊涂了。这个怎么会是构造注入呢？难道不是setter？这个@Provide是Guice module里面的东西，相当于你的Spring manual wiring的<bean>。只不过，你可以方便地做post-construct，不需要容器提供任何特殊的支持。 我的意思是更像构造注入而不是方法注入,方法注入是指标准的setter,要抠字眼的话构造方法也是方法 |
| 返回顶楼 | |
