`

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
〉存在的就是合理的
太对了,就像马家决,
评论

相关推荐

    spring与ejb的区别

    ### Spring与EJB3.0的关键区别及其优劣分析 #### 一、Spring框架概述 **1.1 引言** Spring作为一个广受欢迎的开源框架,最初被设计用于减轻企业级应用开发中的复杂性问题。它的一个显著特点在于模块化的分层架构...

    spring集成ejb

    2. **Spring对EJB的支持**:Spring通过`LocalContainerEntityManagerFactoryBean`支持JPA实体管理,并提供了`EjbFactoryBean`来创建EJB实例。此外,Spring还支持声明式事务管理和安全管理,这使得Spring可以很好地与...

    spring和EJB3的一些包

    Spring 和 EJB3 是两种在企业级 Java 应用开发中广泛使用的框架。Spring 框架以其轻量级、模块化和灵活的设计而闻名,而 EJB3(Enterprise JavaBeans 3)则是 Java EE(现在称为Jakarta EE)平台的一部分,提供了...

    struts2+spring+ejb3源代码(完整版)

    Struts2、Spring和EJB3是Java Web开发中的三个重要框架,它们分别在MVC模式、依赖注入和企业级服务方面发挥着关键作用。这个压缩包提供的源代码是一个完整的项目示例,展示了如何将这三个框架集成到一个应用程序中。...

    ejb spring

    2. **Spring AOP与ejb事务管理**:Spring的声明式事务管理可以与ejb的事务管理相结合,提供更细粒度的事务控制。 3. **Spring与ejb的协作**:在某些场景下,会话bean可能只负责协调工作,而具体的业务逻辑由Spring...

    spring with ejb3

    2. **使用Spring管理EJB**:Spring可以作为EJB的客户端,通过`JndiTemplate`或`InitialContext`查找并使用EJB。 3. **EJB 3在Spring中的配置**:可以使用`@EJB`注解在Spring Bean中注入EJB,或者在Spring XML配置...

    Struts2+Spring+EJB框架整合实例

    Struts2、Spring和EJB(Struts2+Spring+EJB,简称SSE)是Java企业级开发中常用的三大框架,它们各自承担着不同的职责,共同构建了一个强大的应用架构。Struts2作为MVC(Model-View-Controller)框架,负责处理用户...

    POJO Application Frameworks_ Spring Vs. EJB 3

    标题与描述:“POJO Application Frameworks_ Spring Vs. EJB 3” 该标题与描述指出了一篇关于POJO(Plain Old Java Object)应用框架的文章,主要对比了Spring框架与EJB 3.0(Enterprise JavaBeans 3.0)。文章...

    Hibernate+Spring+EJB+Ajax-关于这四种技术的详细讲解

    在IT行业中,Hibernate、Spring、EJB(Enterprise JavaBeans)和Ajax是四个非常重要的技术,它们各自在软件开发的不同方面发挥着关键作用。下面将分别详细介绍这些技术,并探讨它们之间的协同工作方式。 **...

    Struts + Spring + EJB3 demo

    Struts、Spring和EJB3是Java开发中的三个重要框架,它们在企业级应用程序开发中发挥着关键作用。Struts提供了MVC(Model-View-Controller)架构,Spring强化了依赖注入和面向切面编程,而EJB3则是Java EE平台上的...

    EJB3.0和Spring比较

    【EJB3.0与Spring比较】 EJB3.0和Spring是两种广泛使用的Java企业级应用程序开发框架,它们在很多方面有所不同,这些差异主要体现在以下几个关键点: 1. **厂商无关性(Vendor Independence)** - EJB3.0遵循开放...

    struct ,spring,ejb架构原理培训

    本培训主要围绕三个核心话题展开:Structs、Spring和EJB(Enterprise JavaBeans),这些都是Java开发中的重要组成部分。 首先,让我们深入了解Structs。Structs是一个基于MVC(Model-View-Controller)设计模式的轻...

    ajax、spring、ejb试题

    Spring 还支持多种持久层技术,如 JDBC、Hibernate 和 JPA,并且可以与其他Java EE组件如EJB集成。 【EJB】 EJB(Enterprise JavaBeans)是Java EE平台的核心组件之一,用于构建可部署的、分布式的企业级应用程序。...

    struts,spring,ejb3.0

    6. **示例应用**:在实际项目中,比如一个电子商务系统,Struts 2处理用户界面交互,Spring管理业务逻辑和服务调用,而EJB 3.0负责数据库操作和事务处理,例如订单创建、库存更新等复杂流程。 7. **最佳实践**:在...

    EJB&Spring;详细对比

    ### EJB与Spring详细对比分析 #### 一、引言 在现代企业级应用开发领域,EJB(Enterprise JavaBeans)与Spring框架均扮演着重要角色。随着技术的发展与需求的变化,两者之间的对比成为了业界广泛关注的话题。本文...

    spring+struts+ejb整合

    在IT行业中,Spring、Struts和EJB是三个非常重要的框架,它们分别专注于不同领域的应用开发。Spring是一个全面的后端开发框架,提供依赖注入、AOP(面向切面编程)、MVC(模型-视图-控制器)以及大量的企业级服务。...

    struts2 + ejb3 + spring 整合了

    在本文中,我们将探讨如何将三个流行的Java EE框架——Struts2、EJB3和Spring——集成在一起,形成一个强大的企业级应用。这个整合过程对于初学者来说可能会有些复杂,但通过逐步指导,我们将简化这一过程。我们使用...

    10.客户端——Struts 2+Spring+EJB架构实现

    Struts 2、Spring 和 EJB 是 Java Web 开发中的三个关键框架,它们共同构建了一个强大的客户端应用程序架构。本文将深入探讨这三个框架如何协同工作,以及它们各自在企业级开发中的角色。 首先,Struts 2 是一个...

Global site tag (gtag.js) - Google Analytics