ADF Business Components - Part 3

Business Components (continue)

Creating Data Model Components:


In this chapter you will learn how to expose data to a client application. ADF BC does not allow MVC applications to access entity object definitions and associations directly. Instead, you select exactly what data you want clients to be able to access by exposing it through data model components (view object definitions, view link definitions, application module definitions).

The first part of this chapter shows how to create view object definitions and later in the chapter you will learn how to use view link definitions to represent relationships between your view object definitions and using application module definitions to aggregate the data and relationships that an application will need.

Remember these facts about view object definitions:

A view object definition is the representation of a SQL query.
A view object definition includes view attributes for every column in the query result set. The attribute types are Java classes that correspond to the SQL types of the columns.
View attributes can be, but do not need to be, based on entity attributes.
Associated with each view object definition is an XML file containing tags representing the query, the view attributes, and any entity objects that contain entity attributes that the view attributes are based on.
Also associated with each view object definition is a class that contains a number of methods that return view rows, which represent one row from the query.

View Attributes, Entity Attributes, and Caching:

View attributes can, but do not need to, be based on entity attributes. View attributes based on entity attributes are called entity-derived view attributes and other view attributes are called SQL-only view attributes.
The primary difference between the two is the way in which they are cached.  Caching is holding copies of data in memory, which generally optimizes performance.  ADF BC’s caching optimizes performance by holding data in the middle tier, eliminating repeated trips to the database.

This section discusses how values for entity-derived and SQL-only view attributes are cached and then explains how to decide whether a particular attribute should be entity-derived or SQL-only.


View attributes can, but do not need to, be based on entity attributes. View attributes based on entity attributes are called entity-derived view attributes and other view attributes are called SQL-only view attributes.
The primary difference between the two is the way in which they are cached.  Caching is holding copies of data in memory, which generally optimizes performance.  ADF BC’s caching optimizes performance by holding data in the middle tier, eliminating repeated trips to the database.

This section discusses how values for entity-derived and SQL-only view attributes are cached and then explains how to decide whether a particular attribute should be entity-derived or SQL-only.

When a view object instance with entity-derived view attributes first executes its query, it sends the query to the database. The database returns a result (shown below).

The columns in the query result are mapped to view attributes and to entity attributes they are base on, as shown below.

Next, entity object instances are created, and the attributes are populated with the appropriate result column data, and inserted into caches (one for each entity object definition), as shown below.

Finally, view rows are created, and the attributes are populated with pointers to the entity attributes in the entity cache. These view rows are inserted into the view cache for the view object instance.

How Entity-Derived View Attributes are Populated

In summary, there are two sorts of caches:

Entity caches

View caches

As entity-derived attributes are concerned, entity caches hold the data in those attributes, and view caches hold pointers to the data.

How SQL-Only Attributes are Populated:

SQL-only view attributes retrieve data from the database just as entity-derived attributes do. However, after the data is retrieved, SQL-only view attributes are NOT added to the entity cache. Instead, when the view cache is created, the appropriate attribute is populated directly with the data, instead of a pointer to data in an entity cache as shown below:

The only reason to use an entity-derived attribute is to make changes to a database column. From Chapter 9, all updates to a database are made through persistent entity attributes. If you need to change a database column, it must do it through an entity-derived view attribute based on a persistent entity attribute.

If you do not need to make changes (the attribute is read-only) a SQL-only attribute is more efficient than an entity-derived attribute because it skips the step of storing the data in the entity cache and maintaining a pointer to it.

However, there are a few reasons you might want to use an entity-derived attribute