What is a View Object

A View Object is a Business Component that encapsulates SQL code and metadata that maps columns in the SELECT statement to attributes of one or more Entity Objects. A View Object uses SQL to join, filter, and sort business data, shaping it for presentation. View Objects provide clients with row sets they can scroll through and update without concern for or knowledge of the underlying Entity Objects. Figure 1 shows a View Object named EmpNames. EmpNames operates on the Emp Entity Object to provide a view of the EMPNO and ENAME columns of the EMP table.

Figure 1: Relationship between a View Object, Entity Object, and the Underlying Database Table

View Objects are often used to:

Provide an additional level of security by restricting access to a predetermined set of rows and columns. For example, you could create a view where columns containing sensitive data (such as salaries) are not selected.
Hide data complexity. For example, a view can display columns or rows from multiple entities. Such a view hides the fact that the data is coming from several tables.
Customize presentation. Using a view, you can rename columns without affecting the entities on which the view is based.
Store complex queries. A query could perform extensive calculations on table data. By saving this query in a view, the calculations are performed only when the view's query is executed.
Improve efficiency of the application by using fast-executing, optimized SQL, selecting only the data you need.

You can define multiple View Objects per Entity Object, and a View Object can select data from multiple Entity Objects. Data is cached at the Entity Object level. All View Object references within the same transaction share the cache, so changes made through one View Object are immediately available to other View Objects in the same transaction. Figure 2 shows View Objects named DeptEmp and EmpNames. Both View Objects select data from the Emp Entity Object. DeptEmp also selects data from the Dept Entity Object.

Figure 2: View Object Selecting from Multiple Entity Objects

When you define a View Object, you can specify which underlying Entity Objects are read-only and which support read/write operations on participating attributes in the View Object's attribute list. For example, when defining a View Object based on the EMP and DEPT tables (with associated Emp and Dept Entity Objects) you can specify that Emp information should be modifiable, while Dept information is presented only as supporting information.

View Objects can be linked master-detail by View Links in an Application Module. In the Application Module wizard, you can choose the View Links that you want to use. View Links can also be specified in code that executes at runtime. Detail View Objects are automatically synchronized with their respective master View Objects.

An Application Module can use the same View Object more than once. For example, you could provide views of the DEPT and EMP tables linked master-detail by a View Link, and a top-level view of the EMP table as shown in the following figure. In the Application Module wizard, you can specify aliases to represent the various usages of a given View Object. In Figure 3, the alias for the DeptView is MyDeptView. The View Object EmpView has two aliases: MyEmpDetailView (used in a master-detail link) and MyEmpView (used to present a top-level view).

Figure 3: Application Module using a Master-Detail View (DeptView) and a Top-level View (EmpView)

View Objects at Runtime

The typical sequence of what happens at runtime is:

Client code initializes an Application Module. An Application Module contains one or more related View Objects, connects to the database, and provides a context for database transactions.
A View Object provides a runtime reference to a query. You can specify a query using wizards at design time, or by hard-coding a literal SQL string. At runtime, you can create and instantiate View Objects, and you can find and reuse ones that are already instantiated by calling methods on the Application Module.
When a View Object executes its query, it operates on data from one or more tables represented by one or more Entity Objects. Oracle Business Components implements a pull model to refresh View Objects: a View Object does not execute its query until an iterator requests data.
After executing a query, you can call View Object methods to navigate through the result set. If you don't want to work with the entire result set, you can set a range and work with a specified number of rows. Each row of the result set is represented by a Row object; each attribute of a Row object represents a column value in that row. Clients manipulate data by getting and setting row attribute values within the transaction context provided by the Application Module. Changes to data through views are automatically validated by the encapsulated business logic in one or more Entity Objects on which each View Object is based. This encapsulation separates business logic from the user interface.
Commit the changes (if any) to the database to make the updated data available to other Application Modules and other users.