就像我們在設計模式4中看到的, Entity Bean的實現(xiàn)大小被縮減到在ejbCreat(), getData()and setData()方法中的僅僅幾行,不管CMP字段的數(shù)目.下一步是建模公司和雇員的Entity Beans,這個有點繁瑣而且建議讀者先對borland公司的的OR Mapping和高級CMP有所了解.對這個關系建模根本不需要對結構的代碼變化,然而Entity Beans實現(xiàn)類需要一點點修改來反映兩個實體間的關系,鑒于此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的遠程引用現(xiàn)在是CMP的.現(xiàn)在的問題是怎么在getData()和SetData()方法中更新公司Entity Bean的引用,當這些方法只get和set comId(在設計模式上下文中沒有被CMP)的值.簡單的說,過程的結構沒有變化并且字段comId(不再CMP)在RPC中被拷貝到Entity Bean和從Entity Bean拷貝出來.需要的是對公司Entity Bean的遠程引用在必須被寫入數(shù)據(jù)庫和從數(shù)據(jù)庫讀出時更新.我們需要用ejbLoad()和ejbStore()方法在Entity Bean實現(xiàn)類中為我們完成這項工作.在雇員Entity Bean中的ejbLoad()方法的代碼片段如下：
public void ejbLoad() {
try {
comId=(company ==
null)?null:(Integer)company.getPrimaryKey();
} catch (Exception e) {
//throw some runtime exception (e.g. EJBException)
}
}
以上代碼幾乎不需要解釋.當數(shù)據(jù)被從數(shù)據(jù)庫中讀出(在事務的開始時候),comId(不是CMP)字段在雇員Entity Bean被set.因此當getData()方法被調(diào)用時,返回的結構將包含正確地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)
}
}
象以前, 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的遠程引用現(xiàn)在是CMP的.現(xiàn)在的問題是怎么在getData()和SetData()方法中更新公司Entity Bean的引用,當這些方法只get和set comId(在設計模式上下文中沒有被CMP)的值.簡單的說,過程的結構沒有變化并且字段comId(不再CMP)在RPC中被拷貝到Entity Bean和從Entity Bean拷貝出來.需要的是對公司Entity Bean的遠程引用在必須被寫入數(shù)據(jù)庫和從數(shù)據(jù)庫讀出時更新.我們需要用ejbLoad()和ejbStore()方法在Entity Bean實現(xiàn)類中為我們完成這項工作.在雇員Entity Bean中的ejbLoad()方法的代碼片段如下：
public void ejbLoad() {
try {
comId=(company ==
null)?null:(Integer)company.getPrimaryKey();
} catch (Exception e) {
//throw some runtime exception (e.g. EJBException)
}
}
以上代碼幾乎不需要解釋.當數(shù)據(jù)被從數(shù)據(jù)庫中讀出(在事務的開始時候),comId(不是CMP)字段在雇員Entity Bean被set.因此當getData()方法被調(diào)用時,返回的結構將包含正確地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)
}
}