A Preliminary Overview of Java Data Object Technology JDO

As a new language, Java defines a standard runtime environment where user-defined classes are executed. These user-defined instances represent data in the real environment, including data stored in databases, files, or some large transaction processing systems, A small system usually requires a local mechanism to control data storage.

Because the data access technology is different in different data source types, accessing data has become a challenge for developers, programmers need to use specific APIs for each type of data source, that is, they must know at least two languages to develop business applications based on these data sources: the Java language and the data access language determined by the data source. This data access language varies with data sources, which increases the development cost of learning to use a data source.

Before the release of Java Data Object Technology (JDO), there are usually three methods to store Java data: Serialization (also called Serialization) the CMP method in JDBC and EJB. Serializing is used to write the state of an object and the structure diagrams of other objects to an output stream (such as files and networks ), it ensures the relationship between the written objects, so that the object structure can be completely re-constructed at another time point. However, serialization does not support transaction processing, querying, or sharing data with different users. It only allows access based on the granularity of the initially serialized object (the precision of the interface for accessing the object), and is difficult to maintain when the application needs to process multiple or multiple serializations. Serialization is only applicable to the simplest applications, or in some embedded systems that cannot effectively support databases.

JDBC requires that you explicitly process data fields and map them to the tables of the relational database. Developers are forced to deal with two data models, languages, and data access methods that are very different: Java, and relational data models in SQL. During development, it is so complicated to map relational data models to Java object models that most developers never define object models for data; they simply write procedural Java code to manipulate data tables in the underlying relational database. The final result is that they cannot get any benefit from object-oriented development.

The EJB component system is designed to support distributed object computing. It also supports Container management continuity Container management Persistence (see the glossary) for continuity. Mainly because of their distributed features, EJB applications are much more complex than JDO and consume more resources. However, JDO is designed to be flexible. In this way, JDO products can be used to implement the storage and processing of ejbs at the underlying layer, so as to be combined with EJB containers. If your application requires OSS but does not require distributed features, you can use JDO instead of EJB components. The most typical JDO usage scheme in the EJB environment is to allow the Session Bean in the EJB to directly access the JDO object and avoid using the Entity Bean ). The EJB component must run in a Managed application service environment (for more information, see the glossary. However, the JDO application can run in a controlled environment or an uncontrolled independent environment, which allows you to flexibly select the most suitable application runtime environment.

If you focus on designing a Java object model and then use JDO to store your data class instances, you will greatly improve productivity and development efficiency. You only need to process an information model. JDBC requires you to understand the relational model and SQL language, provides simpler data storage interfaces ). You have to learn many other aspects related to the EJB system even when you are using the ejb cmp (that is, the storage for volume control, refer to the glossary, in addition, there are some limitations that do not exist in modeling.
JDO standardizes the conventions between the JDO runtime environment and your storage object classes. JDO is designed to support a variety of data sources, including data sources that are generally not considered in databases. From now on, we use the concept of Database (refer to the glossary) to represent any underlying data source that you access through JDO.

This chapter will discuss the basic capabilities of JDO, which are based on detailed analysis of a small application developed by a virtual Media Mania company. The company rents out and sells entertainment audio and video products in many stores throughout the United States. There are some kiosks in their stores that provide information about movies and actors in movies. This information is available to customers and store staff to help select products that suit the customer's taste.

Define Data Object Model

We will create a UML class diagram to show the related classes of a company's object model and their relationships. A Movie object represents a specific Movie. Each actors playing at least one role in a movie is represented by an Actor (Actor) object. The Role class represents a specific Role played by an actor in a movie. Therefore, the Role class also represents a relationship between a movie and an actor, this relationship contains an attribute (role name in a movie ). Each movie contains one or more roles. Each actor can assume different roles in different movies, or even multiple roles in the same movie.

We will put these data classes and programs that manipulate these data class instances into the com. mecdiamania. prototype package.

Classes to be stored

We define the Movie, Actor, and Role classes to be sustainable, indicating that their instances can be stored in the database. First, let's take a look at the complete source code of each class. Each class has a package statement, so you can clearly see the package in which each class is used in this example.

Example 1-1 shows the source code of the Movie class. JDO is defined in the javax. jdo package. Note that this class does not have to be imported into any specific JDO class. References in Java and collections in the java. util package and related sub-classes (interfaces) are used to represent the relationship between our classes, which is the standard method in most Java applications.

The attributes in the Movie class use standard types in Java, such as String, Date, and int. You can declare an attribute as private without defining the get and set methods for each attribute. The Movie class also has some methods used to access these private attributes. Although these methods are used in other parts of the program, they are not required by JDO. You can use property packaging to provide only the methods required for abstract modeling. This class also has some static attributes that are not stored in the database.

The "genres" attribute is a String type, and the content is the style of the movie to which the movie belongs (action, love, weird, etc ). A Set interface is used to represent the role Set in the cast table of the movie. The "addRole ()" method adds elements to the cast table, while the "getCast ()" method returns a set that cannot be changed, which contains the cast table. These methods are not defined by JDO, but compiled to facilitate application programming. The "parseReleaseDate ()" and "formatReleaseDate ()" methods are used to standardize (Format) the release date of a movie ). To keep the code simple, if parseReleaseDate () is incorrectly formatted, null is returned.

Example 1-1 Movie. java

package com.mediamania.prototype;import java.util.Set;import java.util.HashSet;import java.util.Collections;import java.util.Date;import java.util.Calendar;import java.text.SimpleDateFormat;import java.text.ParsePosition;public class Movie { private static SimpleDateFormat yearFmt = new SimpleDateFormat("yyyy"); public static final String[] MPAAratings = { "G", "PG", "PG-13", "R", "NC-17", "NR"}; private String title; private Date releaseDate; private int runningTime; private String rating; private String webSite; private String genres; private Set cast; // element type: Role private Movie() {} public Movie(String title, Date release, int duration, String rating, String genres) { this.title = title; releaseDate = release; runningTime = duration; this.rating = rating; this.genres = genres; cast = new HashSet(); } public String getTitle() { return title; } public Date getReleaseDate() { return releaseDate; } public String getRating() { return rating; } public int getRunningTime() { return runningTime; } public void setWebSite(String site) { webSite = site; } public String getWebSite() { return webSite; } public String getGenres() { return genres; } public void addRole(Role role) { cast.add(role); } public Set getCast() { return Collections.unmodifiableSet(cast); } public static Date parseReleaseDate(String val) { Date date = null; try { date = yearFmt.parse(val); } catch (java.text.ParseException exc) {} return date; } public String formatReleaseDate() { return yearFmt.format(releaseDate); }}

JDO imposes a requirement on a class to be stored: A non-parameter constructor. If you do not define any constructor in the class code, the compiler will automatically generate a constructor without parameters. If you define a constructor with parameters, you must define a no-argument constructor and declare it as private to prohibit external access. If you do not define this parameter-free constructor, some JDO products will automatically generate one for you, but this is only a function provided by the specific JDO product and cannot be transplanted.

Example 1-2 shows the source code of the Actor class. In our goal, all actors have a unique name to identify themselves. It can be a different alias from the name at birth. Based on this, we use a String to represent the name of the actor. Each Actor may assume one or more roles. The "roles" member in the class indicates the attributes of the Actor in the Actor-Role relationship. The annotation in line ① is only for docalization, and does not implement any special functions for JDO. Line 2 and