Just as we see in the design mode 4, the implementation of the Entity Bean is reduced to ejbcreate (), getData ()
Only a few lines in the and setdata () method, regardless of the number of CMP fields.
The next step is to model the Entity Beans of the model company and employees, this is a bit cumbersome and suggested that the reader is first for Borland.
The company's
The modeling of this relationship does not require changes to the structure of the structure, but the Entity Beans require a little bit.
Modifications to reflect the relationship between the two entities, in view of this deployment descriptor, there is a small modification.
Before before, Entity Bean was inherited from the structure, below is the code snippet of the company 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 include getdata () and setdata ()
Public java.util.collection geteMPloyees () {
Return EMPLOYEES;
}
}
Below is a segment of the employee 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
}
In the above program fragment, the employee Entity Bean inherits from the employee structure, the employee structure itself
A field comID represents the foreign key between employees and companies, in all front design patterns,
This field is CMP. And in the design mode 5 in Deployment Descriptor
The un-checking method is removed from the CMP. And the remote reference to the company's Entity Bean is now CMP.
How is the current problem now updated the reference to the company's Entity Bean in getData () and setData () methods.
When these methods are only GET and SET COMID (there is no CMP in the design mode context).
Simply put, the structure of the process has not changed and the field COMID (no longer cmp) is copied in the RPC to
Entity bean and copy from the Entity Bean. Need is the remoteness of the company's Entity Bean
References are updated when they must be written to the database and read from the database. We need ejbload () and ejbstore ()
Methods to complete this work in the Entity Bean implementation class.
The code snippet of the EJBLOAD () method in the ENTITY bean is as follows:
Public void ejbload () {
Try {
comID = (Company ==
NULL)? NULL: (Integer) Company.getPrimaryKey ();
} catch (exception e) {
// throw some runtime exception (e.g. ejbexception)
}
}
The above code is almost no interpretation. When the data is read from the database (at the beginning of the transaction),
The COMID (not a CMP) field is in the employee Entity Bean Set. Therefore, when the getData () method is called,
The returned structure will contain the value of the correct COMID.
The EJBStore () method in the Entity Bean is as follows:
Public void ejbstore () {
Try {
Company = (COMID == NULL)? Null: beanglossary.getCompanyHome (). FindbyPrimary
Key (COMID);
} catch (exception e) {
// throw some runtime exception (e.g. ejbexception)
}
}
EJBSTORE () is called when the data is completed when the data is written to the database. In this case, the value of the comi
Modified (by calling the setData method), this must be written to the database. Code in the method above
Convert COMID into a company's remote reference. (After all, comid is the primary key of company Entity Bean).
The reason for using empty CHECK is that the database cannot save null values (weak references between tables), and these also need to model.
In any case, Java is better than the basic type of package with Java, because they can
Empty value and easy to convert into other forms.
The code snippet of the Beanglossary class above is easy to confuse.
This is actually a Utility class that captures EJB's Lookup (a stateless session bean),
In the case of Entity Bean and stateful session beans, the lookup of the Home interface is buffered.
In the case of stateless session beans, the Remote interface is buffered (as part of the EJB specification 1.1,
A SLSB called CREATE () is not optimized in the HOME interface).
Through the buffering of the above context, we mean the first request is to be lookup. Subsequent calls are
The HOME interface or Remote interface that has been initialized in the object reference.
The code snippet of the BeanglossarySb Utility class is as follows:
Public class beanglossarysb imports 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 {
IF (CompanyHome == Null)
CompanyHome = (COMPANYHOME)
Javax.rmi.PortableRemoteObject.narrow
getContext (). Lookup ("Java: Comp / ENV / EJB / Company),
CompanyHOME.CLASS)));
Return Company;
}
// rest of the ejbs
}
In the design mode 5, we did not handle the HOME interface of the Entity Bean.
In the case of employee entity beans, there will be a Finder element
In a few lines of FindemPloyeesbyCompany (Company Pcompany),
This will return a collection of employees remote references. Deployment in company Entity Bean
Descriptor Map The Employee Collection of the Finder element defined above.
In this way, the method in the company Entity bean getETemPloyees () call in the Remote interface
Returns the collection of remote references that need to be associated with the company.
