`

Spring VS EJB (2)

阅读更多
Re: 转贴:Spring vs. EJB 发表: 2005年02月07日 11:27 回复
qnabOO1 发表文章: 7/ 注册时间: 2005年02月01日 16:41
>>>>
JdbcDAO是遵循J2EE设计模式的DAO模式,参考Petstored的Category DAO模式,DAO调用方式是: EJB(SKSB) + DAO + JDBC/Hibernate

所以jdbcDAO是被EJB调用的,注意jdbcDAO这段代码中的servicelocator是从哪里导入的,如果我没有记错,应该是 xxx.xxx.xx.ejb.servicelocator。

也就是说,Datasource的Name是EJB的reference name,而reference name是指向数据源的JNDI,JNDI再指向具体数据库。
J2EE就是通过这样的松耦合来实现了解耦。
<<<<
前面关于相机的那段比喻,我确实存在误解。
至于你说得
JdbcDAO是遵循J2EE设计模式的DAO模式,参考Petstored的Category DAO模式,DAO调用方式是: EJB(SKSB) + DAO + JDBC/Hibernate

所以jdbcDAO是被EJB调用的,注意jdbcDAO这段代码中的servicelocator是从哪里导入的,如果我没有记错,应该是 xxx.xxx.xx.ejb.servicelocator。

也就是说,Datasource的Name是EJB的reference name,而reference name是指向数据源的JNDI,JNDI再指向具体数据库。
J2EE就是通过这样的松耦合来实现了解耦。

我还是存有异议,既然你使用了PicoContainer,为何不将解耦进行到底呢?
既然你的JDon 框架很大一部分为了EJB而建立,为何不将PicoContainer作为彻底将你的业务逻辑层 和 EJB/别的J2EE容器解耦的中间层呢? 这样的话,无论对于测试还是部署都有巨大的好处。
针对你说的JDBC DAO,因为在你的源代码中,我找不到你的这些类,我只能就着我的思维发表一点拙见:
可以参考Spring,用一个JndiObjectFactoryBean专门处理JNDI类的引用,下面给出一个转贴以示说明:
<!---->
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName"><value>jdbc/myDatasource</value></property>
<!-- 如果你不想使用 'java:comp/env/'前缀的话请设置下面的值为true, 默认值为false -->
<property name="resourceRef"><value>true</value></property>

<property name="jndiEnvironment">
<props>
<!-- The value of Context.PROVIDER_URL -->
<prop key="java.naming.provider.url">t3://localhost:7001</prop>
<prop key="java.naming.factory.initial">weblogic.jndi.WLInitialContextFactory</prop>


</props>
</property>
</bean> 

"dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
		<property name="driverClassName"><value>org.hsqldb.jdbcDriver</value></property>
		<property name="url"><value>jdbc:hsqldb:data/jert_web_test</value></property>
		<property name="username"><value>sa</value></property>
		<property name="password"><value></value></property>
	</bean>



而你 的 jdbcDAO可以这样写:
public JdbcDAO() {
}
public void setDataSource(DataSource ds){
dataSource=ds;
}

public DataSource getDataSource(){
return dataSource;
}

...

}

你的JDon 配置文件中可以类似这样定义:
<jdbcdao></jdbcdao>
<datasource ref="dataSource"></datasource>
....


如果datasource是自定义的,则只需要这样配置:
<bean id=


既然你的设计使用了IOC的概念,并且采用了PicoContainer为微核心,那么有什么理由不使用IOC呢?


 

Re: 转贴:Spring vs. EJB 发表: 2005年02月07日 11:38 回复
qnabOO1 发表文章: 7/ 注册时间: 2005年02月01日 16:41
其中设置的:

<property name="jndiEnvironment">
<props></props>
<!---->
<prop key="java.naming.provider.url"></prop> t3://localhost:7001
<prop key="java.naming.factory.initial"></prop> weblogic.jndi.WLInitialContextFactory



</property>

实际上就是设置Context初始化的时候设置的Properties属性。

具体请参考:
这个连接:http://faq.lenovo.com/layout/kb/entry.jspa?entryID=12&categoryID=29
至于具体的实现,可以参考Spring的源码。

 

Re: 转贴:Spring vs. EJB 发表: 2005年02月07日 11:48 回复
banq 发表文章: 7433/ 注册时间: 2002年08月03日 17:08
>JDon 框架很大一部分为了EJB而建立,为何不将PicoContainer作为彻底将你的业务逻辑层 和 EJB/别的J2EE容器解耦的中间层
>使用了IOC的概念,并且采用了PicoContainer为微核心,那么有什么理由不>使用IOC呢?

这个问题回答没有那么简单,涉及很多因素,其中有一点是又回到了我们之前讨论的问题上了,我不想将所有的电线象Spring那样暴露在一个配置文件里;或者说暴露给所有应用者。你举例的Spring调用Datasource的方式就象暴露在房间里电线排线一样。

EJB这方面比较巧妙,所以我倾向EJB,当然我没有必要做EJB已经做过的。只要导引用户去用EJB。

JdonFrameowrk既支持EJB,也支持POJO,这个方向你可以使用PicoContainer等极端地装载你所有的业务逻辑层,缺点是:需要象Spring那样进入手工排线阶段。这方面Spring比较擅长,jdonframework可能也不会做,也回只做一个引导。





 

Re: 转贴:Spring vs. EJB 发表: 2005年02月07日 12:09 回复
banq 发表文章: 7433/ 注册时间: 2002年08月03日 17:08
补充:jdonFramework不一定引导到Spring,这些想法还没成熟,正在设计中,最重要的是,将业务逻辑用jdonframework包裹,然后运行在其它容器中,保护已有组件。

试图在探索方向还有: MDA,以及提供POJO自由迁徙到EJB容器等。

 

Re: 转贴:Spring vs. EJB 发表: 2005年02月07日 12:40 回复
qnabOO1 发表文章: 7/ 注册时间: 2005年02月01日 16:41
我个人认为banq 你有一个根本的原则搞混淆了。
“暴露” 和 “可扩展” ,你似乎在两者之间互相矛盾。

一个咚咚可扩展,那么他必须要暴露它所需要的扩展点。
当然,为了简化开发, 默认的Default实现都会随之提供。 这点并没有增大开发人员的开发量。

就像上面的datasource,暴露DataSource是使得开发人员根据具体项目可扩展的关键。
jdbcDAO对于DataSource的获取,暴露给开发人员自己扩展实现,又何偿不可呢 ? 正是因为这样,开发人员可以轻松扩展为从JNDI中获取,或者自己定义。
假设,你的jdbcDAO需要一个用户自己定义的DataSource,那么你必须又得写出另外一个JDBC DAO,此时,你不会跟我拿出J2EE规范跟我说:用户必须在JNDI中定义它的DataSource吧!
另外,看了一下你的cache包,忍不住说两句:
这是典型的重复造车的行为。

现在已经有优秀的多个cache 产品,何必自己实现一个:UtilCache ?
给你一个类似的实现:
cache接口同你一般。


另外参考一些优秀的项目,给你提供一个CacheProvider:

import java.util.Properties;
public interface CacheProvider {


public Cache buildCache(String regionName, Properties properties) throws CacheException;
public long nextTimestamp();

}
对于Cache的实现, 你可以用OSCache 或者JCSCache来实现。
针对每一个不同实现的Cache,分别提供一个CahceProvider以封装生成具体Cache的逻辑。
这样,就使得用户可在配置文件中选择他所需喜欢的Cache:比如OSCache或者JCSCache等等。 用户需要改的仅仅是它所需要的CacheProvider .


 

Re: 转贴:Spring vs. EJB 发表: 2005年02月07日 12:46 回复
banq 发表文章: 7433/ 注册时间: 2002年08月03日 17:08
关于jdonframework到其它帖子讨论,我和你讨论到此为止,我不想说一些伤害你自尊的话,你拿一个个问题来问我,我都可以回答你,可惜这样问题回答太简单,我都开始怀疑你是那个gigix,因为你们的思维和知识水平是类似。

对不起,不要再接我的话题,如果有伤害你,道歉。讨论别的问题的,关于JdonFramework有关于请教的到项目工程论坛吧。

 

Re: 转贴:Spring vs. EJB 发表: 2005年02月07日 13:10 回复
qnabOO1 发表文章: 7/ 注册时间: 2005年02月01日 16:41
声明一点:
我不是gigix!

至于说我与他的观点相同,你倒不如说与你的观点相反罢了。

gigix的帖子我也看了,虽然一些建议显得比较苛刻 ,但是大多数观点还是正确的,只不过你听不进罢了。 我现在本着我个人的观点跟你进行纯粹的基于技术观点的讨论,没想到最后你回了一句:不想讨论了,因为你的问题都很简单。

嘿嘿,简单的问题,你反而用了最复杂的办法来解决,不是嘛 ?
j2EE规范你或许比谁都熟透,但或许这点反而成了你懒得跟别人争论的理由,反而成了“固步自封”的理由。

理论,没必要搞得玄乎其玄,OO倒是可以用似乎很高深的理论来进行辩驳的地方,不过一旦到了基于代码级别的讨论,似乎就可以彰显很多咚咚出来!
不是嘛?

另外,态度决定一切。
看了你明显糊弄一番的demo,不禁大为失望,态度就决定了一切。不是嘛?

 

Re: 转贴:Spring vs. EJB 发表: 2005年02月12日 22:49 回复
IPOz 发表文章: 4/ 注册时间: 2002年08月16日 11:29
EJB是有spec. 但似乎学院派太浓?!结果简单问题搞得较复杂,尤其是那个entity bean :(
我们以前的项目基本上是SLSB+HIBERNATE完成,感谢hibernate :)

“高内聚,松耦合”是每个程序员(还有其它xxx员)都明白的原则吧?spring较漂亮地用IOC等等方法来解耦,也没违背这个原则吧?正因为spring简单而不失强大,才吸引了众多有反叛心的人(包括我:)
目前正试spring+hibernate, 感觉爽, 呵呵!

存在就是合理的,争论千万别伤了和气!

 

Re: 转贴:Spring vs. EJB 发表: 2005年02月13日 11:12 回复
sparkstone 发表文章: 3/ 注册时间: 2005年02月12日 16:55
没必要争了,其实Spring或者叫IoC Container和EJB Container只是实现途径不同罢了,前者用BeanFactory隐藏一切,程序员直接就可以用到POJO,这种做法的好处是便于实施TDD/XP的项目,开发效率高,而后者要求Beans显式继承特定的接口,无法脱离Container来进行测试,但是EJB3已经就这些不足进行了修正,但是EJB Container的好处是显然的,它这种突出Container的优势在于更利于集群、分布式事务处理的标准化实现。看看当年的CICS就知道我们现在把时间花在架构的讨论上是多么可笑了,新技术的目的应当是提高编码效率、质量以及服务器的RAS特性。

 

Re: 转贴:Spring vs. EJB 发表: 2005年02月13日 19:29 回复
banq 发表文章: 7433/ 注册时间: 2002年08月03日 17:08
我再次总结一下之前我叙述的重点。

例如:开发一个商店的J2EE应用系统,需要以下功能:
1. 事务机制、对象池 这属于基础功能,类似房间中的电线。
2. 商品的新增删除修改功能,这属于业务功能。

在目前的Spring中,这两种功能是并列出现在一个配置文件,简单地说:这会带来混乱的感觉,因为基础功能可能不需要经常修改;而业务功能需要经常修改,这就如同代码一样,你将多个功能代码放在一个类的方法中,这是不行的,需要进行分派封装。

我们需要拓展性,就象我们需要房间的电线可以在必要时更改一样,不必裸体,加一件衣服,就如同给电线加上排线管一样,我们给基础功能从业务功能的配置中分离出来,单独打包,需要修改基础功能时,再打开基础功能的配置文件就可以,如同人穿了衣服后,需要透明扩展,就脱了衣服就可以了


过了年,讲话够费劲的,我觉得我前面的帖子讲的够明白了。其实这些精神在GoF设计模式中体现很多,例如装饰模式、代理模式等。

还有关于jdonFramework的两个问题是很简单:
1. JDBCDao的Database名称,了解过EJB开发的人一看就知道,这里serviceLocator是EJB的定位器,是在EJB中用的。这个问题答案很简单。

2. 关于Cache,如果你知道GoF的适配器模式或Wrapper模式,很明显,JdonFramework使用了Wrapper模式,以便用户能够更换更好地的缓存器,缺省的是OfBIz一个缓存器,这缓存器通过配置文件,可以设置缓存失效时间,也就是说,它的缓存是自动更新的。

 

Re: 转贴:Spring vs. EJB 发表: 2005年02月14日 23:07 回复
leji 发表文章: 1/ 注册时间: 2005年02月14日 23:05
我觉得你们的讨论很幼稚。
某人动机也不纯正,时时提起自己的那个%%¥%¥#,
呵呵,走也

 

Re: 转贴:Spring vs. EJB 发表: 2005年02月19日 10:39 回复
siberian 发表文章: 24/ 注册时间: 2003年07月14日 16:24
我自己浅薄,只是觉得ejb的那古怪的oo模式很令人难以接受,而叛逃了。现在ejb3.0这方面有了改善,所以打算回归。

至于别的,谁愿意当技术杂工阿!什么东西都自己拼凑甚至写。反正我没这个水平。spring阿!拿来做个bean工厂就够了。别的太累。别告诉我他有多好,灵活,可扩展,我懒。
那个灵活,可扩展是破坏整体性得来的。条块化,固然隔离了风险,也增加装配的问题。用一个整块的石头做的东西比拼起来的东西结实的多。结晶的时候方向一致嘛!所以大一点的组件更好用,更结实。spring里面东西太碎了。所以懒人我不用。

 

Re: 转贴:Spring vs. EJB 发表: 2005年02月19日 10:42 回复
YuLimin 发表文章: 25/ 注册时间: 2007年01月21日 12:47
深思与学习中。。。

 

ejb 发表: 2005年02月19日 18:55 回复
toadspider 发表文章: 3/ 注册时间: 2004年03月23日 16:14
ejb

 

Re: ejb 发表: 2005年02月19日 18:56 回复
toadspider 发表文章: 3/ 注册时间: 2004年03月23日 16:14
111111

 

Re: 转贴:Spring vs. EJB 发表: 2005年02月22日 15:08 回复
dabb 发表文章: 236/ 注册时间: 2004年04月21日 15:02
tmd,怎么一提ejb就有人吵架。现在叫ejb不好的人两年前估计大部分都是对ejb顶礼膜拜吧。现在ejb2.0的那些缺点早就是大白菜,谁都知道了,也没必要再一直说了。
spring和ejb,从框架的角度来说是,#$#$@#tmd,没意思,不说了

by the way,人家开发出一套东西来,即使是有缺点,也没有必要老是进行攻击吧,看来”文人相轻“的毛病还是改不了。你要用的方便就去用,不方便就自己写了。

 

Re: 转贴:Spring vs. EJB 发表: 2005年02月23日 11:51 回复
一剑封喉 发表文章: 55/ 注册时间: 2004年12月20日 17:11
〉存在的就是合理的
太对了,就像马家决,
评论

相关推荐

Global site tag (gtag.js) - Google Analytics