探讨Spring框架使用真相

04-08-25 banq
http://www.jdon.com/AOPdesign/spring2.htm

flyinair2000
2004-08-26 22:28
我觉得关于“粗粒度”问题在使用aop的框架中不存在。

因为可以把需要事务处理的方法定义成一个aspect,这样结构更加清楚。

flyinair2000
2004-08-27 03:52
不好意思,没有仔细看版主的文章。//版主和俺是一条心啊,hoho

swordwater
2004-08-27 08:52
我觉得是不是Spring包括的面比较广,故就没有重点,我觉得要使用他无法也就用一个Bean Factory还可以,除了这个好像别的framework比他做得强。刚看spring.

banq
2004-08-27 11:30
>Bean Factory

是的,Bean Factory类似微容器,有生命周期,这样,你可以把你的javaBeans装进去带了跑,运行于各种JAVA平台中,我自己是使用piccontainer实现这个的。

swordwater
2004-08-27 16:06
看了老半天也看不出这种framework怎么池化对象?

guan213
2004-08-28 14:09
看了《探讨Spring框架使用真相》,对SPRING的事务作了测试,在不使用EJB容器事务(CMT),在service中使用SPRING的JTA的事务机制。可以做到service中两个DAO的事务同时回滚。经过这两天的调试,现在spring与EJB的关系已经理顺,可以实现真正的分布式EJB。

bullboss
2004-08-29 02:21
spring是不错,关注中.

zingers
2004-08-31 17:20

高级DAO编程,讲解了JDBC事务管理和JTA事务管理

看了就了解了编程式事务的原理和实践。

EJB是申明式事务管理。基于配置,

所以Spring和EJB联合没有必要。

Springwithout EJB才是从他的角度的结果。

还有一点:技术本无高下之分,只有适用之分。

recher
2004-09-06 18:42
我个人觉得Spring的意在建立一种依赖注入DI(反向控制IOC)和面向接口一种编码规范, 他和EJB容器的确用的技术和方法是一样的,但是因为二者的市场和开发需求定位不一样,导致他们在开发的时候对接口的和配置的不一一样,那么对于Spring的结合EJB的容器进行协调必然导致接口的衔接问题.

banq
2004-09-07 12:34
讨论的人不多,看来掌握的人不多,初学者可参考本站VIP会员区的“Spring入门速成”教程。

http://www.jdon.com/my/train/controllAction.do

habc
2004-09-07 15:52
Spring框架使用的真相就是不用ejb,without ejb里面表达的也是这个意思。

对于事务粒度,spring是可以控制的,需要设置回滚的条件:

public void updateUser(){

    updateTabel1();//更新table1

    updateTable2(); //更新table2

  }

如果发生异常指定的异常,对table1,table2的操作都将回滚!

bran
2004-09-08 11:50
我想你证明了原文中关于EJB把真正的逻辑 "委托" 给受Spring管理的POJO 后失去transaction 力度控制的判断是不正确的. 作者应该修改原文这一部分的论述。

使用 Spring 提供的 session bean 的 基类 以后, 用户大致会 不使用 EJB 容器提供的 Transaction 控制 而改用 Spring 的Transaction管理。 这里,Sessionbean 基本上变成了 Spring 管理的业务逻辑的 ejb protocol 的 adapter。

这样做是有意义的。 假如你有一个“老式的” 基于ejb 的应用, 已可以用这种方式逐步地使用Spring提供的方便功能 实现新的业务逻辑或者改造一些老的业务功能。当然, clustering 也许是另外一个给 Sping 穿上 EJB外衣的原因。即使如此, Spring 对 scalability 的 假设是:

一个好的 web container 能为 web applications提供有力的 failover 和clustering 的支持。

这样 Sping 就把 性能的扩展性任务推给了 web container。

banq
2004-09-08 12:26
bran在这方面思考比较深入,大部分观点和我比较相似。有两点值得商酌:

1.关于事务粒度控制方面,目前Spring版本的事务支持粒度确实不是丰富细致,我想这个问题以后会得到提升,特别是分布式环境下的事务回滚,这恐怕Spring在短期内难以做到的,所以我称其为粒度事务控制不是很到位,目前来说应该是不偏激的。

2.Sping 就把 性能的扩展性任务推给了 web container,那么我们就要求有一个好的Web容器提供Cluster支持,但是遗憾的是,目前J2EE标准中并没有和涉及Web容器的任何Cluster定义或接口,所以造成有的Web容器提供Cluster,如tomcat有一些,jetty比较好,大部分商业化产品如Weblogic则没有,它们把Cluster集中在EJB层了。

所以,现在就开始混乱了,有可能使得WEB应用程序和具体Web容器绑定,如Jetty,可移植性和兼容性的恶梦又开始在Web层上演。

大量纯Web层沉淀系统太多了,而J2EE标准又没有给它们指明可拓展性的出路,最后,只能向Tangosol这样收费的分布式缓存产品交费了。

这就是Web层系统性能提升的出路吗?

这个tapestry + spring + hibernate开源先驱也在力度引导我们走入这个方向,有些可悲:

https://betterpetshop.dev.java.net/

作者自称自己是Cluster的,仔细查看,就是采用Tangosol实现,这点是在其http://217.164.144.19:7001/ 演示地址说明的,不过我刚才没有能够访问到http://217.164.144.19:7001/这个Cluster后强大的性能能力,估计已经Down机很长时间了。

bran
2004-09-08 15:11
我会辩解说, ejb 有什么样的粒度, spring 也能提供。

在 jpetstore 示范程序里面, 两个 DAO 对象可以使用不同的datasource, 也就是这样:

	<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
		<property name="jndiName"><value>java:comp/env/jdbc/jpetstore</value></property>
	</bean>

	<!-- Additional JNDI DataSource for J2EE environments -->
	<!-- Refers to the order database, containing order data -->
	<!-- (see dataAccessContext-local.xml for an alternative) -->
	<bean id="orderDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
		<property name="jndiName"><value>java:comp/env/jdbc/jpetstore-order</value></property>
	</bean>

	<bean id="itemDao" class="org.springframework.samples.jpetstore.dao.ibatis.SqlMapItemDao">
		<property name="dataSource"><ref local="dataSource"/></property>
		<property name="sqlMap"><ref local="sqlMap"/></property>
	</bean>

	<!-- Refers to the order database here -->
	<!-- (see dataAccessContext-local.xml for an alternative) -->
	<bean id="orderDao" class="org.springframework.samples.jpetstore.dao.ibatis.SqlMapOrderDao">
		<property name="dataSource"><ref local="orderDataSource"/></property>
		<property name="sqlMap"><ref local="sqlMap"/></property>
		<property name="sequenceDao"><ref local="sequenceDao"/></property>
	</bean>
<p>

这里面 itemDao 和orderDao 使用不同的 datasource, 这两个datasource 都是由 j2ee 容器配置在 JNDI 中的.

在 petStoreImpl中 有这样一个方法

	public void insertOrder(Order order) {
		this.orderDao.insertOrder(order);
		this.itemDao.updateQuantity(order);
	}
<p>

现在我们把perStoreImpl 放到一个 SLSB 中, 有三种管理 transaction 的方法:

- CMT (Container Managed Transactions) wrapping the EJB, delegating to a POJO object wrapped with Spring Transactions.

- CMT wrapping the EJB, delegating to a POJO object not wapped with any Spring transactions.

- NO CMT wrapping the EJB, delegating to a POJO object wrapped with Spring TX.

这三种方法都能达到相同的效果: 完成一个跨越数据库的transaction. 实际上Spring 的作者们似乎更倾向于最后一种方案, 也就是不用 CMT 而全部依靠Spring.

在处理分布交易方面, Spring 似乎并无先天局限性. 放在高端 j2ee 容器中, spring可以使用 容器提供的各种分布式资源, 并正确地完成交易,独立自主地, 或者参与到 CMT 中.

猜你喜欢
5Go 1 2 3 4 ... 5 下一页