Entity Bean's basic theory
1.1 What is Entity Bean Entity Bean is a persistent data component that represents a persistence object stored in an external medium or an existing enterprise application system resource. Simply put, an Entity Bean can record a line of rows in the database, multiple client applications can access the Entity Bean that represents the database record in a shared manner. So what is a lasting data component? Why use persistent data components? Understand these two questions, it also clears the nature and use of Entity Bean. The persistent data component refers to such an object that knows how to put itself in a lasting storage space. They use some persistent mechanisms such as serialization, O / R mapping. This object represents data, such as using the persistent data component represents the following information: ● Bank account information, such as account, password, and balance; ● employee information, such as name, department and salary. Why do they handle these data in the way instead of direct processing of raw data in the database, such as related records? The answer is to treat data as an object is very convenient because it is convenient to operate and manage objects, and they behave as a compact form. In addition, through the application server where the components are located, transactions, security, etc. can be obtained. Entity Bean is this persistent data component. Entity Bean knows how to save yourself permanently in a storage space such as a database. Entity Bean stores data in a field, such as a bank account, password, and balance. Relying on transaction services provided by EJB containers, multiple client applications can realize sharing of data resources under the consistency and integrity of the database record. The life phase of the Entity bean is relatively long and its status is continuous. As long as the database record represented by the Entity bean exists, the component object instance has existed, even if the EJB container crashes, Entity Bean still has vitality.
1.2 The subtype of Entity Bean can divide the Entity Bean into two models of container management persistence (CMP container-management persistence) and component management persistence (BMP bean-managed personistence). In the implementation code of the CMP type EJB component, component developers do not need to write code for any database operations for component's persistent control methods, but automatically create by deployment tools during component assembly and deployment; if you want to create BMP type EJB Components, component programming needs to write control code for all persistence methods.
1.3 Entity Bean features a data record in the database, each entity type EJB component contains a primary key, which is the same as the database record primary key represented by the component. Client applications can use this primary key to locate the ENTITY bean object instance in the EJB container, and the database records represented by the component. The main features of the entity type EJB component include: ● Entity bean provides views of the records recorded in the database; ● EJB server can use the passivate method of entity bean to cache the Entity bean into the temporary storage space, can also use the Activate method to re-read the cached ENTITY bean into the EJB container and restore the component object instance; ● Client application can be used in Entity Create, deletion, and query defined in the bean's HOME interface manages the components.
Using EJB QL Development Query 2.1 What is EJB QL in the operation of the relational database is often used frequently, mainly through the SELECT statement. Entity Bean also requires query operations as a persistent component representing data in a database, that is, an instance of Entity Bean that meets a query condition can be found. The query operation of the Entity bean is done by defining the finder () method. For CMP, define the Finder () method is merely declaring a method, indicating the parameters of the Finder () method, which is usually corresponding to the parameters in the query condition, and the actuated action is done by the EJB container. The EJB container is to read the
ECBP and CMP selection EJB have two main types of BMP (bean managed persistence) and CMP (Container Managed Persistence), which have advantages and disadvantages. BMP is a variety of calls to database JDBC in Bean, that is, in your entity bean (entity bean), it is clearly written to SQL statement, such as "INSERT .." or "SELECT ..", and Use DataSource to get a database resource and connection (Connection) to add delete modifications directly to the database. CMP is automatically completed by the EJB container to the database, all of which is done, that is, in the entity bean re-writes the setxxx or getxxx method, then define CMP-Field in EJB-JAR.XML. Obviously, CMP is more simple, and database operations should be a trend that the EJB container should be a trend, but CMP has a shortcoming is not flexible. If we have to complete the like command similar to SQL search statement, such as "SELECT * from a where Name Like '% banqiao' ", CMP can not automatically help us complete, so we need BMP yourself to write. In practical applications, we will generally use CMP in order to use CMP, but how to prepare to use BMP in the future, that is, there is a basis that can extend to BMP. EJB 2.0 provides us with this implementation of this implementation for the abstract class support of CMP. Overall idea is, first using abstract class to complete CMP If you need BMP to extend this abstract class, then override the original method (this method is overwritten with your own special SQL statement).
In the pet store address of the entity bean Java (Java Pet Store Demo 1.3) of: AddressEJB Example: public abstract class AddressEJB implements EntityBean {private EntityContext context = null; // getters and setters for PO CMP fieldspublic 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); setlastn AME (LNAME); SETSTREET1 (S1); setStreet2 (S2); 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 AddresseJB, we see only SETXXX or GETXXX methods.
In the corresponding deployment description file EJB-JAR.XML we see:
