当前页面位置: » 丰搜网 » 文档中心 » 详细内容
ejb设计模式5
就像我们在设计模式4中看到的, entity bean的实现大小被缩减到在ejbcreate(), getdata()and setdata()方法中的仅仅几行,不管cmp字段的数目.下一步是建模公司和雇员的entity beans,这个有点繁琐而且建议读者先对borland公司的<ejb程序员指南>的or mapping和高级cmp有所了解.
对这个关系建模根本不需要对结构的代码变化,然而entity beans实现类需要一点点修改来反映两个实体间的关系,鉴于此deployment descriptor需要有小的修改.
象以前, entity bean从结构继承,下面是公司entity bean的代码片段:
public class companybean extends companystruct
implements entitybean {
entitycontext entitycontext;
// cmp for all fields in the companystruct
public java.util.collection employees; //one-to-many
//rest of the code including getdata() and setdata()
public java.util.collection getemployees() {
return employees;
}
}
下面是雇员entity bean的程序片段:
public class employeebean extends employeestruct
implements entitybean {
entitycontext entitycontext;
//cmp for all fields in employeestruct except
//the comid
public company company;//remote reference to company
}
在上面的程序片段中,雇员entity bean从雇员结构继承,雇员结构本身有
一个字段comid表示雇员和公司之间的的外键,在所有的前面的设计
模式中,
这个字段是cmp的.而在设计
模式5中这个字段用在deployment descriptor中un-checking的方法从cmp中去掉.而对公司entity bean的远程引用现在是cmp的.现在的问题是怎么在getdata()和setdata()方法中更新公司entity bean的引用,当这些方法只get和set comid(在设计
模式上下文中没有被cmp)的值.简单的说,过程的结构没有变化并且字段comid(不再cmp)在rpc中被拷贝到entity bean和从entity bean拷贝出来.需要的是对公司entity bean的远程引用在必须被写入
数据库和从
数据库读出时更新.我们需要用
ejbload()和
ejbstore()方法在entity bean实现类中为我们完成这项工作.
在雇员entity bean中的
ejbload()方法的代码片段如下:
public void ejbload() {
try {
comid=(company ==
null)?null:(integer)company.getprimarykey();
} catch (exception e) {
//throw some runtime exception (e.g. ejbexception)
}
}
以上代码几乎不需要解释.当数据被从
数据库中读出(在事务的开始时候),
comid(不是cmp)字段在雇员entity bean被set.因此当getdata()方法被调用时,返回的结构将包含正确地comid的值.
在雇员entity bean中的
ejbstore()方法如下:
public void ejbstore() {
try {
company = (comid ==
null)?null:beanglossary.getcompanyhome().findbyprimary
key(comid);
} catch (exception e) {
//throw some runtime exception (e.g. ejbexception)
}
}ejbstore()在事务结束当数据被写入
数据库时被调用.在这种情况下,comid的值被修改(通过调用setdata方法),this必须被写到
数据库中.在上面方法中的代码把comid转化成公司的远程引用.(毕竟comid是公司entity bean的主键).
使用空check的原因是
数据库不能存空值(表之间的弱引用),并且这些同样需要建模.
任何情况下,用
java对基本类型的封装要比使用基本类型自己好,因为他们能
存空值而且易于转换成其他形式.
上面的beanglossary类的代码片断容易引起一些混淆.
这实际上是一个捕获
ejb的lookup的utility类(一个无状态session bean),
在entity bean和有状态session bean的情况下,home接口的lookup是被缓冲的.在无状态session bean的情况下,remote接口是被缓冲的(作为
ejb规范1.1的一部分,一个slsb在home接口中调用的create()是不被优化的).
通过在上面上下文的缓冲,我们意思是第一个请求是被lookup的.随后的调用是得到已经在对象引用中初始化的home接口或remote接口.
beanglossarysb utility类的代码片段如下:
public class beanglossarysb implements sessionbean {
private context context = null;
public javax.naming.context getcontext() throws
namingexception {
if (context == null)
context = new javax.naming.initialcontext();
return context;
}
// company
private companyhome companyhome = null;
public companyhome getcompanyhome() throws
namingexception {
companyhome = ((companyhome)
javax.rmi.portableremoteobject.narrow(
getcontext().lookup("java:comp/env/ejb/company"),
companyhome.class));
return companyhome;
}
// rest of the ejbs
}在设计
模式5中,我们没有处理entity bean的home接口.
在雇员entity bean的情况下, 会有一个finder元素在
findemployeesbycompany(company pcompany)的几行中,
这将会返回雇员远程引用的集合. 在公司entity bean 中的deployment
descriptor map了在上面定义的finder元素的雇员集合.
这样,在公司entity bean中的方法getemployees()在remote接口中的调用
返回需要的与那家公司相联系的远程引用的雇员的集合.
--
