Shulou(Shulou.com)06/02 Report--

Most people do not understand the knowledge points of this "EJB Design pattern case Analysis" article, so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "EJB Design pattern case Analysis" article.

As we saw in design pattern 4, the implementation size of Entity Bean is reduced to EJBCreate (), getData ()

There are 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 companies and employees, which is a bit tedious and suggests readers to borland first.

The company's OR Mapping and advanced CMP have some knowledge.

Modeling this relationship does not require code changes to the structure at all, while the Entity Beans implementation class requires a little bit

Modifications to reflect the relationship between the two entities, in view of this Deployment Descriptor requires minor modifications.

As before, Entity Bean inherits from the structure, and the following is a snippet of the company's 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

}

}

The following is a snippet of the employee Entity Bean program:

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, which itself has

One field, comId, represents the foreign key between the employee and the company, in all previous design patterns

This field belongs to CMP. In design mode 5, this field is used in Deployment Descriptor.

Un-checking 's method is removed from CMP. The remote reference to the company Entity Bean is now CMP.

The question now is how to update references to the company Entity Bean in the getData () and SetData () methods

When these methods are only the values of get and set comId (not CMP in the context of the design pattern).

Simply put, the structure of the process does not change and the field comId (no longer CMP) is copied to the

Entity Bean and copied from Entity Bean. What is needed is remote access to the company's Entity Bean

References are updated when they must be written to and read from the database. We need to use ejbLoad () and ejbStore ()

Method to do this for us in the Entity Bean implementation class.

The snippet of the ejbLoad () method in the employee 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 hardly needs to be explained. When the data is read from the database (at the beginning of the transaction)

The comId (not CMP) field is set in the employee Entity Bean. So when the getData () method is called,

The returned structure will contain the value of the correct comId.

The ejbStore () method in the employee 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 at the end of the transaction when the data is written to the database. In this case, the value of comId

To be modified (by calling the setData method), the this must be written to the database. The code in the above method

Convert the comId into a remote reference to the company. After all, comId is the key to the company's Entity Bean.

The reason for using null check is that the database cannot store null values (weak references between tables), and these also need to be modeled.

In any case, encapsulation of primitive types in java is better than using primitive types themselves, because they can

Empty values are stored and easily converted into other forms.

The code snippet of the BeanGlossary class above can easily cause some confusion.

This is actually a utility class (a stateless session bean) that captures EJB's lookup

In the case of entity bean and stateful session bean, the lookup of the Home interface is buffered.

In the case of stateless session bean, the Remote interface is buffered (as part of the ejb specification 1.1

Create () called by a SLSB in the Home interface is not optimized.

By buffering the context above, we mean that the first request is lookup. The subsequent call is to get the

A home interface or remote interface that has been initialized in an object reference.

The code snippet for the BeanGlossarySB utility class is as follows:

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 {

If (companyHome = = null)

CompanyHome = (CompanyHome)

Javax.Rmi.PortableRemoteobject.narrow (

GetContext () .lookup (java:comp/env/ejb/Company)

CompanyHome.class))

Return companyHome

}

/ / rest of the EJBs

}

In design mode 5, we do not have a Home interface for Entity Bean.

In the case of employee Entity Bean, there will be a finder element in the

In several lines of findEmployeesByCompany (Company pCompany)

This will return a collection of employee remote references. Deployment in the company Entity Bean

Descriptor map has a collection of employees for the finder element defined above.

Thus, the method getEmployees () in the company Entity Bean is called in the remote interface

Returns the required collection of remotely referenced employees associated with that company.

The above is about the content of this article "case Analysis of EJB Design pattern". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.