2外文翻译编写容器管理持久性实体Bean.docx

1、2外文翻译编写容器管理持久性实体BeanWriting Container-Managed Persistent Entity BeansContainer-Managed FieldsA container-managed persistent entity bean allows the container to handle some or all of its data access logic. Rather than coding JDBC or SQL/J operations in your bean class, your container implicitly perfo

2、rms all database operations behind the scenes.With container-managed persistence, you must make some of your entity bean classs fields public so that the container can set the fields when it performs database operations on behalf of your bean. The fields that you want to be persistent are called con

3、tainer-managed fields. You dont have to worry about setting these fieldsthe EJB container will automatically manipulate them for youbehind the scenes when it performs storage operations.One restriction of container-managed fields is that every field you want to be managed by the container must follo

4、w the rules for Java object serialization (we describe these rules in full in Appendix A). This means that primitive types such as doubles and Booleans, as well as serializable classes such as primary key classes or EJB handles to other entity beans, can be container-managed fields.For example, the

5、following is a snippet of code from our bank account entity bean class that we wrote in Chapter 8:With container-managed persistence, the container can persist each of these fields for you behind the scenes. When saving your bean instances fields, the container is responsible for querying your bean

6、instance for these field values. When loading data into your bean instance, the container sets these fields. This is possible because each of the fields is declared as public.Of course, you still must inform the container about which fields it should manipulate. You specify this in your beans deploy

7、ment descriptor. The EJB container will inspect the deployment descriptor to figure out which of your entity beans fields to manipulate.Note that not all fields within the bean have to be managed by the container. You might be pulling data manually from a secondary source, or you might have calculat

8、ed fields. The EJB container will automatically notify your bean class during persistent operations, allowing you to manage these fields.Primary Key ClassAs with bean-managed persistence, container-managed persistence dictates that your primary key class must be serializable. Because the EJB contain

9、er will work with your primary key, there are new restrictions for how you write your primary key class. The most important restriction is that the fields you have in your primary key must come from the container-managed fields of your entity bean, which we described previously. This restriction all

10、ows the EJB container to set, as well as extract, your entity beans primary key fields.For example, take our primary key class from our Chapter 8s bank account:This is a valid primary key class for container-managed persistence because its serializable and because its public fields come from our bea

11、n classs container-managed fields.Implementation Guidelines for Container-Managed PersistenceThe method implementations of your entity beans should be different for container-managed persistent entities. No longer are you controlling the routine persistent operations of your beans, and so many of th

12、e methods can be left emptythe container will do it for you. Table 9.1 is a summary of what you should implement in each method, assuming your entity beans persistence is container managed. Take a quick glance at the chart for now. As you can see from the table, many of the database-intensive operat

13、ions have been reduced in scope significantly. You should refer back to the chart when reading through the code in this chapter or when programming your own entity bean classes. The order of methods listed very roughly models the flow of control of an entity bean instances life cycle that we saw at

14、the end of Chapter 7.Container-Managed Persistence Example:A Product LineLets see a quick demonstration of container-managed persistence in action, applied to the concept of a product line.If youre working for a product-based company, your companys product line is the suite of products your company

15、offers. For example, if youre an appliance company, you might offer a dishwasher, a stove, and a dryer. If youre a computer hardware company, you might offer memory, hard disks, and processors. Were going to model a generic product as an entity bean that uses container-managed persistence.The object

16、 model for our product line is detailed in Figure 9.1.Lets take a look at each of the files that we must create for our entity bean component.Product.javaOur remote interface is specified by Product.java, shown in Source 9.1.Our remote interface is very similar to Chapter 8s bank account remote inte

17、rface. It has methods to modify the entity bean instances fields and throws remote exceptions to indicate system-level errors.ProductHome.javaNext, we have the products home interface, ProductHome.java, presented in Source 9.2Our home interface defines a single create() method to create a new produc

18、t in the database. It returns a Product EJB object so the client can manipulate the entity bean data and throws a javax.ejb.CreateException to indicate an application-level problem.We also expose all sorts of finder methods to find existing products. Some of the finders return a single EJB object, w

19、hile others return a java.util.Enumeration of multiple EJB objects. This is needed if the finder methods find more than one matching object. Note that findByPrimaryKey() should never return an enumeration because primary keys must be unique.ProductPK.javaOur primary key class is defined by ProductPK

20、.java, shown in Source 9.3.As with our Bank Account, our primary key is a simple string. And as weve found out, there are restrictions for what our primary key can be. Our primary key fields are coming from the container-managed fields of the entity bean class, as is required with container-managed

21、persistence. In particular, our primary key represents the ID string of a product (such as a product SKU number).ProductBean.javaNext, we have our container-managed entity bean implementation, ProductBean.java, shown in Source 9.4.This bean is more complex than our bank account example. Weve defined

22、 many finder methods, and we have four persistent fields. Yet even though weve added all this complexity, our bean is less than 40 percent of the size of our Bank Account bean. This is an amazing reduction in code complexity. And because our bean has no database code in it, we have reduced the chanc

23、e for bugs in our bean that would be due to user error working with JDBC code. This is a huge savings in development and testing time.We have four container-managed fields, all with public scope. Theyre public so that the container can manipulate them. Our ejbCreate() method simply sets our containe

24、r-managed fields to the passed-in client parameters. The EJB container will extract those fields and set up the database data for us. Notice that our ejbCreate() method does not return a primary key because the EJB container does that for us.The rest of our bean is just empty methods and comments. T

25、heres almost no logic at all. Our bean class is just data with some accessor methods.Client.javaOur client code is a simple suite of test cases to try out our bean, as shown in Source 9.5.We perform a JNDI lookup to acquire the home object and create some entity bean data. We then try out a couple o

26、f finder methods. We can loop through the finders returned numerations and call business methods on each EJB object. We then destroy all the EJB objects we created in a finally clause.The Deployment DescriptorWe now need to write our deployment descriptor. In addition to defining the standard entity

27、 bean fields, we now need to inform the container about our public container-managed fields. The deployment descriptor is shown in Table 9.2. Notice that we no longer have any JDBC application-specific properties because weve externalized all database activity to the container.In addition to the dep

28、loyment descriptor, we need to tell the container exactly how to perform persistent operations. This is one trade-off of container-managed persistenceyou still need to declare persistent rules, rather than code them into your bean using JDBC or SQL/J.If youre using a relational data store, youll nee

29、d to define exactly how your entity beans public fields map to that database. Thus, we must define a series of object-relational mapping entries. These entries map entity bean fields to relational database column names. The EJB container (in this case, BEA WebLogic) will use this mapping when storin

30、g or retrieving our container-managed fields from the database. Note that this is very EJB container-specific! Some EJB containers will support object databases and thus will not have a mapping into a two-dimensional relational database. Consult your EJB containers documentation for more information

31、. Our product lines persistent entries for BEAs WebLogic server are shown in Table 9.3.We also need to specify the implementation of our home objects finder methods. This is also, unfortunately, proprietary for each EJB container. BEA WebLogic has a simple scripting language for this purpose. For ex

32、ample:The complete script is shown in Table 9.4. The container will implement this logic, perhaps using JDBC or SQL/J. Whenever a client wants to execute a finder method on the home object, the container will automatically run the implemented JDBC or SQL/J code.Running the Client ProgramTo run the client program, type a command similar to the following (depending on what your EJB container Java Naming and Directory Interface, or JNDI, initialization parameters are):The initialization parameters are required by JNDI to find the home object, as we learned in