| Red Hat Docs > Manuals > Red Hat Web Application Framework > |
|
A persistence layer has been developed as part of Red Hat Web Application Framework for the purpose of encapsulating the database access routines. The API provided for the persistence layer allows application and service developers to work with a standard set of objects that read and save their state to a relational database. In previous versions of Red Hat Web Application Framework (CCM), the applications communicated directly with a relational database by putting the SQL statements directly in the TCL scripts. The problems identified with the TCL approach included scalability issues, difficulties with upgrading to later versions, and excess code was needed to maintain database independence. By encompassing the SQL statements in Java objects, the database access routines can be developed in a scalable environment. Additionally, the applications are isolated from the schema changes (which may occur in future versions), since the database access routines are encapsulated by a standard API.
For more information regarding "object-relational persistence," see the following third-party links:
The persistence layer developed for Red Hat Web Application Framework is located at:
http://ccm.redhat.com/doc/core-platform/5.0/api/com/arsdigita/persistence/package-summary.html |
The objects that you will be modeling as part of your persistence layer are commonly referred to as Data Objects. Data Objects are responsible for handling all aspects of persisting object data and retrieving object data from the database.
The documentation is divided into the following sections:
the section called Data Objects Tutorial discusses what Data Objects are, how to define object types within PDL, and how to use these Data Objects to access information stored in the database.
the section called Transaction Management contains documents about how to use the full features of PDL. It describes how the persistence layer deals with the section called Transaction Management. It also discusses how to give the persistence layer hints about how to retrieve information from the database.
the section called Persistence Architecture Overview details the requirements and design that were used in building the persistence layer.
the section called Persistence Glossary contains information that can provide references for users of persistence. It begins with a glossary of terms and is followed by a document detailing the PDL grammar and syntax (the section called PDL Syntax). It also includes an index to the documentation to provide easy access to the information you need.
This documentation assumes familiarity with the concepts outlined in the the section called Persistence System Overview section as well as the terms defined in the the section called Persistence Glossary. If all else fails, you may find the the section called Frequently Asked Questions to be useful.
The persistence layer can be looked at as a way to access objects within the database. Examples of objects that can be stored in the database are Users, Groups, Articles, Images, and Email Addresses. In Red Hat Web Application Framework TCL, if a developer wanted to store some information in the database about the user, he had to have intimate knowledge about how users were modeled within the database. Most of the time, this simply involved knowing which row of which table to look up. However, occasionally a single object (for example, a User) was stored across rows of many tables, and the object's associations with other objects in the database were stored in additional tables.
In order to abstract out the information regarding object storage within the database, the persistence layer has implemented the concept of a single Data Object. Data Objects are used by Java classes to handle all interaction with the database. Because this API is provided, other classes do not need to know how to create, retrieve, update, or delete a given object. Data Objects are defined by their Attributes, Object Key, and Events. This design pattern follows the pattern set forth in the J2EE Blueprints. For more information, refer to: http://java.sun.com/j2ee/blueprints/design_patterns/data_access_object/index.html
Now that it is possible to perform operations on single objects using Java Data Objects, the next logical extension is to be able to relate those objects to each other. For instance, it is often desirable to have a database of images that can be included within articles on a web site. Therefore, it must be possible to indicate that a certain article uses a certain image. This concept is represented in persistence by a Association. Data Associations allow developers to indicate that one object is related to another object. They also provide a mechanism that allows developers to answer the questions, "What images does this article use?" and "What articles use this image?"
The Data Object class provides a way for developers to retrieve object attributes and associations. However, when a developer wants to order the associations by a sort key, or only wants the association with the lowest sort key, the solution is to use Filter and Order conditions. Filters allow the developer to restrict attribute values, while Order allows the association to be sorted by various attribute values. For more information, see the the section called Filtering, Ordering, and Binding Parameters document.
While using Data Objects and filtering associations will work for most situations, occasionally developers need to obtain information from custom queries or perform specific updates or inserts. Therefore, the persistence system contains the concept of a Named SQL Operation. Specifically, Data Queries can be used to obtain arbitrary information from the database and Data Operations can be used to execute arbitrary DML statements. See the Data Objects tutorial for more information on: the section called Data Operations
PDL is the name of the language used by developers to define data objects and associations. Please see the section called Data Objects and PDL: How are they related? for more information.