EJB设计模式5

就像我们在设计模式4中看到的,EntityBean的实现大小被缩减到在ejbCreate(),getData()
andsetData()方法中的仅仅几行,不管CMP字段的数目.
下一步是建模公司和雇员的EntityBeans,这个有点繁琐而且建议读者先对borland
公司的<EJB程序员指南>的ORMapping和高级CMP有所了解.
对这个关系建模根本不需要对结构的代码变化,然而EntityBeans实现类需要一点点
修改来反映两个实体间的关系,鉴于此DeploymentDescriptor需要有小的修改.
象以前,EntityBean从结构继承,下面是公司EntityBean的代码片段:
publicclassCompanyBeanextendsCompanyStruct
implementsEntityBean{
EntityContextentityContext;
//CMPforallfieldsintheCompanyStruct
publicjava.util.Collectionemployees;//one-to-many
//restofthecodeincludinggetData()andsetData()
publicjava.util.CollectiongetEmployees(){
returnemployees;
}
}
下面是雇员EntityBean的程序片段:
publicclassEmployeeBeanextendsEmployeeStruct
implementsEntityBean{
EntityContextentityContext;
//CMPforallfieldsinEmployeeStructEXCEPT
//thecomId
publicCompanycompany;//remotereferencetocompany
}
在上面的程序片段中,雇员EntityBean从雇员结构继承,雇员结构本身有
一个字段comId表示雇员和公司之间的的外键,在所有的前面的设计模式中,
这个字段是CMP的.而在设计模式5中这个字段用在DeploymentDescriptor中
un-checking的方法从CMP中去掉.而对公司EntityBean的远程引用现在是CMP的.
现在的问题是怎么在getData()和SetData()方法中更新公司EntityBean的引用,
当这些方法只get和setcomId(在设计模式上下文中没有被CMP)的值.
简单的说,过程的结构没有变化并且字段comId(不再CMP)在RPC中被拷贝到
EntityBean和从EntityBean拷贝出来.需要的是对公司EntityBean的远程
引用在必须被写入数据库和从数据库读出时更新.我们需要用ejbLoad()和ejbStore()
方法在EntityBean实现类中为我们完成这项工作.
在雇员EntityBean中的ejbLoad()方法的代码片段如下:
publicvoidejbLoad(){
try{
comId=(company==
null)?null:(Integer)company.getPrimaryKey();
}catch(Exceptione){
//throwsomeruntimeexception(e.g.EJBException)
}
}
以上代码几乎不需要解释.当数据被从数据库中读出(在事务的开始时候),
comId(不是CMP)字段在雇员EntityBean被set.因此当getData()方法被调用时,
返回的结构将包含正确地comId的值.
在雇员EntityBean中的ejbStore()方法如下:
publicvoidejbStore(){
try{
company=(comId==
null)?null:beanGlossary.getCompanyHome().findByPrimary
Key(comId);
}catch(Exceptione){
//throwsomeruntimeexception(e.g.EJBException)
}
}
ejbStore()在事务结束当数据被写入数据库时被调用.在这种情况下,comId的值
被修改(通过调用setData方法),this必须被写到数据库中.在上面方法中的代码
把comId转化成公司的远程引用.(毕竟comId是公司EntityBean的主键).
使用空check的原因是数据库不能存空值(表之间的弱引用),并且这些同样需要建模.
任何情况下,用java对基本类型的封装要比使用基本类型自己好,因为他们能
存空值而且易于转换成其他形式.
上面的BeanGlossary类的代码片断容易引起一些混淆.
这实际上是一个捕获EJB的lookup的utility类(一个无状态sessionbean),
在entitybean和有状态sessionbean的情况下,Home接口的lookup是被缓冲的.
在无状态sessionbean的情况下,Remote接口是被缓冲的(作为ejb规范1.1的一部分,
一个SLSB在Home接口中调用的create()是不被优化的).
通过在上面上下文的缓冲,我们意思是第一个请求是被lookup的.随后的调用是得到
已经在对象引用中初始化的home接口或remote接口.
BeanGlossarySButility类的代码片段如下:
publicclassBeanGlossarySBimplementsSessionBean{
privateContextcontext=null;
publicjavax.naming.ContextgetContext()throws
NamingException{
if(context==null)
context=newjavax.naming.InitialContext();
returncontext;
}
//Company
privateCompanyHomecompanyHome=null;
publicCompanyHomegetCompanyHome()throws
NamingException{
if(companyHome==null)
companyHome=((CompanyHome)
javax.rmi.PortableRemoteObject.narrow(
getContext().lookup("java:comp/env/ejb/Company"),
CompanyHome.class));
returncompanyHome;
}
//restoftheEJBs
}
在设计模式5中,我们没有处理EntityBean的Home接口.
在雇员EntityBean的情况下,会有一个finder元素在
findEmployeesByCompany(CompanypCompany)的几行中,
这将会返回雇员远程引用的集合.在公司EntityBean中的Deployment
Descriptormap了在上面定义的finder元素的雇员集合.
这样,在公司EntityBean中的方法getEmployees()在remote接口中的调用
返回需要的与那家公司相联系的远程引用的雇员的集合.