軟件設(shè)計:EJB設(shè)計模式5

字號:

就像我們在設(shè)計模式4中看到的, Entity Bean的實現(xiàn)大小被縮減到在ejbCreat(), getData()and setData()方法中的僅僅幾行,不管CMP字段的數(shù)目.下一步是建模公司和雇員的Entity Beans,這個有點繁瑣而且建議讀者先對borland公司的的OR Mapping和高級CMP有所了解.對這個關(guān)系建模根本不需要對結(jié)構(gòu)的代碼變化,然而Entity Beans實現(xiàn)類需要一點點修改來反映兩個實體間的關(guān)系,鑒于此Deployment Descriptor需要有小的修改.
    象以前, Entity Bean從結(jié)構(gòu)繼承,下面是公司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從雇員結(jié)構(gòu)繼承,雇員結(jié)構(gòu)本身有一個字段comId表示雇員和公司之間的的外鍵,在所有的前面的設(shè)計模式中,這個字段是CMP的.而在設(shè)計模式5中這個字段用在Deployment Descriptor中un-checking的方法從CMP中去掉.而對公司Entity Bean的遠(yuǎn)程引用現(xiàn)在是CMP的.現(xiàn)在的問題是怎么在getData()和SetData()方法中更新公司Entity Bean的引用,當(dāng)這些方法只get和set comId(在設(shè)計模式上下文中沒有被CMP)的值.簡單的說,過程的結(jié)構(gòu)沒有變化并且字段comId(不再CMP)在RPC中被拷貝到Entity Bean和從Entity Bean拷貝出來.需要的是對公司Entity Bean的遠(yuǎn)程引用在必須被寫入數(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)
    }
    }
    以上代碼幾乎不需要解釋.當(dāng)數(shù)據(jù)被從數(shù)據(jù)庫中讀出(在事務(wù)的開始時候),comId(不是CMP)字段在雇員Entity Bean被set.因此當(dāng)getData()方法被調(diào)用時,返回的結(jié)構(gòu)將包含正確地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()在事務(wù)結(jié)束當(dāng)數(shù)據(jù)被寫入數(shù)據(jù)庫時被調(diào)用.在這種情況下,comId的值被修改(通過調(diào)用setData方法),this必須被寫到數(shù)據(jù)庫中.在上面方法中的代碼把comId轉(zhuǎn)化成公司的遠(yuǎn)程引用.(畢竟comId是公司Entity Bean的主鍵).使用空check的原因是數(shù)據(jù)庫不能存空值(表之間的弱引用),并且這些同樣需要建模.
    任何情況下,用java對基本類型的封裝要比使用基本類型自己好,因為他們能
    存空值而且易于轉(zhuǎn)換成其他形式.上面的BeanGlossary類的代碼片斷容易引起一些混淆.這實際上是一個捕獲EJB的lookup的utility類(一個無狀態(tài)session bean),
    在entity bean和有狀態(tài)session bean的情況下,Home接口的lookup是被緩沖的.在無狀態(tài)session bean的情況下,Remote接口是被緩沖的(作為ejb規(guī)范1.1的一部分,一個SLSB在Home接口中調(diào)用的create()是不被優(yōu)化的).通過在上面上下文的緩沖,我們意思是第一個請求是被lookup的.隨后的調(diào)用是得到已經(jīng)在對象引用中初始化的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
    }
    在設(shè)計模式5中,我們沒有處理Entity Bean的Home接口.在雇員Entity Bean的情況下, 會有一個finder元素在findEmployeesByCompany(Company pCompany)的幾行中,這將會返回雇員遠(yuǎn)程引用的集合. 在公司Entity Bean 中DeploymentDescriptor map了在上面定義的finder元素的雇員集合.這樣,在公司Entity Bean中的方法getEmployees()在remote接口中的調(diào)用返回需要的與那家公司相聯(lián)系的遠(yuǎn)程引用的雇員的集合.