7.9 Summary of Difference Between Entity-Based View Objects and Read-Only View Objects

You now know that view objects can either be related to underlying entity objects or not. This section helps summarize the difference between the runtime behavior of these two fundamental kinds of view objects.

7.9.1 Runtime Features Unique to Entity-Based View Objects

When a view object has one or more underlying entity usages you can create new rows, and modify or remove queried rows. The entity-based view object coordinates with underlying entity objects to enforce business rules and to permanently save the changes. In addition, you've seen that entity-based view objects:

Immediately reflect pending changes made to relevant entity object attributes made through other view objects in the same transaction
Initialize attribute values in newly created rows to the values from the underlying entity object attributes
Reflect updated reference information when foreign key attribute values are changed

7.9.2 View Objects with No Entity Usage Are Read-Only

View objects with no entity usage are read-only, do not pick up entity-derived default values, do not reflect pending changes, and do not reflect updated reference information. You need to decide what kind of functionality your application requires and design the view object accordingly. Typically view objects used for SQL-based validation purposes, and for displaying the list of valid selections in a dropdown list, can be read-only. There is a small amount of runtime overhead associated with the coordination between view object rows and entity object rows, so if you don't need any of the functionality offered by an entity-mapped view object, you can slightly increase performance by using a read-only view object with no related entity objects.

7.9.3 What You May Need to Know About Enabling View Object Key Management for Read-Only View Objects

An entity-based view object delegates the task of finding rows by key to its underlying entity row parts. When you use the findByKey() method to find a view row by key, the view row turns around and uses the entity definition's findByPrimaryKey() to find each entity row contributing attributes to the view row key.

This scheme is not possible for a read-only view object since it has no underlying entity row to which to delegate the job. Since you might use read-only view objects to quickly iterate over query results without needing any of the additional features provided by the entity-based view object, a read-only view object does not assume you want to incur the slight additional overhead of managing rows by key at the level of the view object's row set.

In order to successfully be able to use the findByKey() method on a read-only view object, you need to perform two additional steps:

Ensure that at least one attribute in the view object has the Key Attribute property set
Enable a custom Java class for the view object, and override its create() method to call setManageRowsByKey(true)after calling super.create() like this:
```
// In custom Java class for read-only view object
public void create() {
  super.create();
  setManageRowsByKey(true);
}
```

Note:

In an application using the ADF Model layer for data binding to a read-only view object, the successful operation of the ADF Faces table — or other controls that allow the end user to set the current row by clicking in the page — require this additional step. This also applies to the successful use of built-in binding layer actions like setCurrentRowWithKey or setCurrentRowWithKeyValue on a read-only view object. These all boil down to calling findByKey() under the covers.

Section 25.3.2, "Implementing Generic Functionality Using Runtime Metadata" describes a generic technique you can use to avoid having to remember to do this on all of your read-only view objects on which you want findByKey() to work as expected.