(Recommended) Basic Theory of Entity Bean (from http://dev2dev.bea.com.cn)

Basic Theory of Entity Bean
1.1 What is Entity Bean
Entity Bean (Entity Bean) is a persistent data component that represents a persistent object or

Existing enterprise application system resources. Simply put, an entity bean can represent a row of records in the database, and multiple Client Applications

Entity Bean that can be accessed in a shared manner to indicate the database record.
So what is a persistent data component? Why use persistent data components? After understanding these two questions, you can understand the entity

The nature and purpose of bean.
A persistent data component refers to an object that knows how to put itself into a persistent storage space. They use some persistence

Mechanism, such as serialization and O/R ing. This type of object represents data. For example, using the persistent data component represents the following information:
● Bank account information, such as account number, password, and balance;
● Employee information, such as name, department, and salary.
Why do we need to process the data as objects instead of directly processing the original data in the database, such as related records?

? The answer is that it is very convenient to regard data as objects, because objects can be conveniently operated and managed, and they are shown as a compact form.

In addition, you can obtain services such as transactions and security through the application server where the component is located.
Entity Bean is such a persistent data component. Entity Bean knows how to save permanently in a bucket such as a database

Yourself. Entity Bean stores data in fields, such as bank accounts, passwords, and balances.
Depending on the transaction service provided by the EJB container, multiple client applications can maintain the consistency and integrity of database records.

To share data resources. Entity Bean has a long life cycle and its status is continuous. As long as the entity bean represents

If the database record exists, the component object instance always exists. Even if the EJB container crashes, the entity bean remains alive.

1.2 subtype of Entity Bean
According to the implementation form of Entity Bean persistence, Entity Bean can be divided into container management persistence (CMP

Container-managed persistence) and Component Management persistence (BMP bean-managed persistence) models. In

In the implementation code of CMP-type EJB components, component developers do not need to write any database operation code for the persistent Control Method of components.

Is automatically created by the deployment tool during component assembly and deployment. If you want to create a BMP-type EJB component, the component program designer

You need to write control code for all persistence methods.
1.2 subtype of Entity Bean
According to the implementation form of Entity Bean persistence, Entity Bean can be divided into container management persistence (CMP

Container-managed persistence) and Component Management persistence (BMP bean-managed persistence) models. In

In the implementation code of CMP-type EJB components, component developers do not need to write any database operation code for the persistent Control Method of components.

Is automatically created by the deployment tool during component assembly and deployment. If you want to create a BMP-type EJB component, the component program designer

You need to write control code for all persistence methods.

1.3 features of Entity Bean
Corresponds to data records in the database. Each entity-type EJB component contains a primary key identifier, which corresponds

The component indicates that the primary keys of database records are the same. Client Applications can use this primary key to locate the Entity Bean object instance in the EJB container.

Locate the database records represented by the component.
The main features of Object-type EJB components include:
● Entity Bean provides the record view in the database;
● The entity bean has an unlimited life cycle, and the failure of the EJB server does not affect the existence of the Entity Bean;
● Multiple entity beans can correspond to the same database record;
● The EJB server can use the passivate method of Entity Bean to cache Entity Bean to a temporary bucket.

The activate method is used to re-read the cached entity bean into the EJB container and restore the component object instance;
● Client applications can manage components by using methods defined in the home interface of Entity Bean, such as creation, deletion, and query.

.

Query by using EJB QL
2.1 What is EJB QL
In relational database operations, queries are often used, mainly through the SELECT statement. Entity Bean as generation

The persistence component of the data in the table database also needs query operations, that is, instances that meet certain query conditions can be found.

. The query operation of Entity Bean is completed by defining the finder () method. For CMP, defining the finder () method is just to declare

Method, indicating the parameters of the finder () method. This parameter usually corresponds to the parameters in the query condition.

. The EJB container reads the <query> item in the deployment description file ejb-jar.xml (in *. Jar/META-INF), which contains

The query statement corresponding to the finder () method. <Query> the query statement follows the ejb ql syntax.
The steps for querying the development of ejb ql are as follows:
1> Add the finder () method to the home interface. Its parameters are the parameters used in the query conditions;
2> define the ejb ql statement in the <query> item of the ejb-jar.xml file.
EJB Ql is a new feature of ejb2.0. It defines various search methods in the home interface. It is based on SQL-92

Can be automatically compiled by the container, which makes Entity Bean more portable and easy to deploy.
An ejb ql statement consists of three clauses: Select, where, and orderby. The last two clauses are optional.
An example of an ejb ql query statement is as follows:
Example 1:
Select Stu from student as Stu where Stu. Grade> 5
This query statement is used to query the student bean instance of grade> 5. "Student" is the name of the abstract mode (Abstract

Schema name), the name specified by the <ABSTRACT schema Name> item in the ejb-jar.xml file. "Stu" is the alias of student

The benefit of introducing aliases is that you can reference the fields of the object. Stu. Grade indicates the grade field of student, which is called a path expression.

.
Example 2:
Select I from student as I where I. Name =? 1
The meaning of this query statement is to find the student bean instance with the same name as the first parameter in the finder () method.
Use of where statements:
★To? N represents the input parameters of the corresponding finder () method;
★String-type values must be enclosed in single quotes (if the value contains single quotes, double quotation marks are used instead)
The expressions and operators that can be used in the where statement are as follows:
☆+,-, *,/, =, <, <=, >=,>, <>, Not, And, or
☆Between
☆Like
☆In
☆Member
☆Is null (is not null)
Built-in functions:
● Concat (string first, string second)
● Substring (string source, int start, int length)
● Locate (string source, string patter)
● Length (string source)

BMP and CMP selection of object beans

EJB has two main types: BMP (bean managed persistence) and CMP (container managed persistence ).

Each type has its own advantages and disadvantages.

BMP is used to call database JDBC in bean, that is, in your entity bean, it is explicitly written

SQL statements, such as "insert..." or "Select...", and use datasource to obtain a database resource and Connection

(Connection) to directly add, delete, and modify the database.

CMP is performed on the database automatically by the EJB container. All you do is to rewrite the setxxx or getxxx method in the object bean. However

Then you can define CMP-field in the ejb-jar.xml.

Obviously, CMP writing is much simpler, and database operations should be performed by EJB containers. However, CMP has a disadvantage that it is not good enough.

If we want to complete the like Command similar to the SQL search statement, such as "select * from a where name like

'% Banqiao' ", CMP cannot help us automatically, so we need to write BMP ourselves.

In practical application, we usually try to use CMP for efficiency considerations. But how to prepare for the possibility of using BMP in the future is that it is feasible

To extend to the basis of BMP. The support for CMP abstract classes in EJB 2.0 provides the basis for this implementation.

The general idea is to first use an abstract class to complete the CMP. If you need BMP, you can extend this abstract class, and then overwrite the original method (use your own

).

Take the address Entity Bean: addressejb in Java pet store demo 1.3 as an example:

Public abstract class addressejb implements entitybean {
Private entitycontext context = NULL;

// Getters and setters for Po CMP Fields

Public abstract string getfirstname ();
Public abstract void setfirstname (string name );
Public abstract string getlastname ();
Public abstract void setlastname (string name );
Public abstract string getstreet1 ();
Public abstract void setstreet1 (string name );
Public abstract string getstreet2 ();
Public abstract void setstreet2 (string name );
Public abstract string getcity ();
Public abstract void setcity (string name );
Public abstract string getstate ();
Public abstract void setstate (string name );
Public abstract string getcountry ();
Public abstract void setcountry (string name );
Public abstract string getzip ();
Public abstract void setzip (string name );

Public object ejbcreate (string fname, string lname, string S1,
String S2, string cy, string St,
String cnty, string pcode)
Throws createexception {
Setfirstname (fname );
Setlastname (lname );
Setstreet1 (S1 );
Setstreet2 (S2 );
Setcity (CY );
Setstate (ST );
Setcountry (cnty );
Setzip (pcode );
Return NULL;
}

Public void ejbpostcreate (string fname, string lname, string street1,
String street2, string city, string state,
String country, string zip)
Throws createexception {}
Public void setentitycontext (entitycontext c) {context = C ;}
Public void unsetentitycontext (){}
Public void ejbremove () throws removeexception {}
Public void ejbactivate (){}
Public void ejbpassivate (){}
Public void ejbstore (){}
Public void ejbload (){}
}

In the above addressejb, we can see that only setxxx or getxxx methods are available.

In the corresponding deployment description file ejb-jar.xml we see:

<Entity>
<Display-Name> addressejb </display-Name>
<EJB-Name> addressejb </EJB-Name>
<Local-Home> com. Sun. J2EE. Blueprints. Address. EJB. addresslocalhome </Local-Home>
<Local> com. Sun. J2EE. Blueprints. Address. EJB. addresslocal </local>
<EJB-class> com. Sun. J2EE. Blueprints. Address. EJB. addressejb </EJB-class>
<Persistence-type> container </persistence-type>
<Prim-key-class> JAVA. Lang. Object </prim-key-class>
<Reentrant> false </reentrant>
<CMP-version> 2.x</CMP-version>
<Abstract-schema-Name> address </abstract-schema-Name>

<CMP-field>
<Field-Name> firstname </field-Name>
</CMP-field>
<CMP-field>
<Field-Name> lastname </field-Name>
</CMP-field>
<CMP-field>
<Field-Name> street1 </field-Name>
</CMP-field>
<CMP-field>
<Field-Name> street2 </field-Name>
</CMP-field>
<CMP-field>
<Field-Name> city </field-Name>
</CMP-field>
<CMP-field>
<Field-Name> state </field-Name>
</CMP-field>
<CMP-field>
<Field-Name> country </field-Name>
</CMP-field>
<CMP-field>
<Field-Name> zip </field-Name>
</CMP-field>

<Security-identity>
<Description> </description>
<Use-caller-identity> </use-caller-identity>
</Security-identity>

</Entity>

In the above deployment file, the address database field is marked:

Firstname, lastname, street1, street2, city, state, country, zip

Once we use BMP, we only need to inherit the above CMP Bean:

Public class addressbeanbmp extends addressejb {

Use our own BMP method to overwrite the method in addressejb:

Ejbload () --> obtain data from the database (select)
Ejbstore () --> modify Database Data Update)
Ejbremove () --> delete database data)
Ejbcreate () --> insert)
Ejbfindbyprimarykey (primary key) --> ensure that the primary key exists.
Ejbfindallprimarykey () --> return the collectionxiam of all data records of a primary key.

The following uses ejbcreate () as an example:

Public object ejbcreate (string fname, string lname, string S1,
String S2, string cy, string St,
String cnty, string pcode) throws createexception {

// Insert row into database
This. fname = fname;
This. lname = lname;
This. S1 = S1;
This. S2 = S2;
This. Cy = Cy;
This. St = sT;
This. cnty = cnty;
This. pcode = pcode;

// Insert database record
Try {
Connection connection = getconnection ();
Preparedstatement = connection. preparestatement
("Insert into address (firstname, lastname, street1, street2, city, state, country, zip) Values

(?, ?, ?,?,?,?) ");
Statement. setstring (1, fname );
Statement. setstring (2, lname );
Statement. setstring (3, pcode );
Statement. setstring (4, S1 );
Statement. setstring (5, S2 );
Statement. setstring (6, St );
Statement. setstring (7, CY );
Statement. setstring (8, cnty );
If (statement.exe cuteupdate ()! = 1 ){
Statement. Close ();
Connection. Close ();
Throw new createexception ("cocould not create :");
}
Statement. Close ();
Connection. Close ();
}
Catch (sqlexception e ){
Throw new ejbexception ("cocould not create :");
}
}