Overview

The data access layer consists of two main parts: entity detail access and list access. The entity detail access provides CRUD (Create Read Update Delete) operations and look up methods (finder framework) for the entities defined in the repository. The list access provides read-only methods to fetch entities data in a table form. The list access uses a supplementary reporting framework. The reporting framework is used to create a persistent set of object ids according to some business criteria. This set is supplied as a parameter to the list access methods.

Entity detail and list access methods provide API which operates with business model artifacts (i.e. EntityType, Field, FieldPath, Logical key etc.). This effectively isolates the data access layer's business logic from the persistence aspects. In most cases developers do not need to take care about persistence technologies like hibernate or jdbc.

Data access layer also has different extension points which can be used to adjust default persistence logic. Developer usually need to create extensions if the business model has been modified or extended in a non standard way. Before contributing extensions in the data access layer, please consider other possibilities like hpm command framework. Keep in mind that data access layer extensions should be used to adjust persistence logic and should not be used to implement business logic!

Most of the data access implementation logic uses meta information to perform data manipulation operations (deletion, search, update, hql queries generations etc). This meta information is composed from persistence fields defined in the repository (called mappings) and JPA persistence entity called persistence meta model. JPA entities itself are called persistence model. See further section for more details.

Detail access

Detail models can be accessed using EntityManager. On this level entity details are represented as EMF/SDO EDataGraph (data transfer object used in HPM platform). The EntityManager provides read, save, delete and find operations and isolates persistence layer from the application layer (business layer and platform services). It also takes care about detail model in memory caching, find results caching and change notification.

List access

List models can be loaded using the ListModelLoadService. List access is a read-only method to get large sets of tabular data. List columns are defined using same terms as used in entity detail access (i.e. FiledPaths, EntityType etc.). So the list access is used to get a flat table of the entity detail graphs. List access provides optimized version of list which is based on the lazy loading principal - table rows are loaded block-by-block as soon as they are really needed. It helps to reduce memory consumption. List access uses the reporting framework to define which rows should be loaded. Reporting framework provides a possibility to create sets of internal object ids according to some business criteria. These sets are persisted in the database and have identifiers (reportId). Business creterias (reports) are usually defined using Stored Procedures. However it is also possible to define reports in runtime using search.