A view object is a class that lets you define and work with a set of rows, often in service of a user interface. Typically, a view object contains a SQL query that selects data from a database. It can be associated with underlying entity objects so you can modify data in the database, or not be associated with entity objects at all.
A view object uses a SQL query to specify filtered subsets of business data that can be related to attributes from entity objects. You create views based on what the client needs to display The views of data can be based on but are independent of the underlying entity objects, enabling flexible data retrieval to support the required UI. In other words, you can query a set of data exactly as you want to show it in the display. The view object defines the attributes of the view row class, which represents a row in the query result, and optionally refers to underlying entity objects. View objects provide clients with row sets they can scroll through and update without concern for or knowledge of the underlying entity objects. Clients manipulate data by navigating through the result set, getting and setting attribute values; changes are made to the data in the underlying database when the transaction is committed. Relationships between view objects are expressed using view links. Each view object provides a default iterator that you can use to navigate through its result set.
For example, the following figure shows the relationship between a view object, entity object, and the underlying database table. A view object named EmpNames operates on the Emp entity object to provide a view of the EMPNO and ENAME columns of the EMP 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 object where columns containing sensitive data (such as salaries) are not selected.
Hide data complexity. For example, a view object can display columns or rows from multiple entity objects. Such a view object hides the fact that the data is coming from several tables.
Customize presentation. Using a view object, you can rename columns without affecting the entity objects on which the view object is based.
Store complex queries. A query could perform extensive calculations on table data. By saving this query in a view object, the calculations are performed only when the view object's query is executed. The calculation is executed before the data is retrieved from the database.
Improve efficiency of the application by using fast-executing, optimized SQL, selecting only the data you need.
You can define the following general types of view objects, either at design time or dynamically at runtime:
|
Does the view object contain a SQL query? |
Does at least one view attribute map to an entity attribute? |
You can use the view object for... |
And you get these benefits... |
| yes | yes | querying, updating, inserting, and deleting data | data consistency with other view objects that map to the same entity objects, and memory savings |
| yes | no | querying data | less overhead (and potentially faster) than when you map to entity objects, especially when using forward only mode (where there is no view caching) |
| no | yes | inserting data | no initial query is executed, which saves startup time |
| no | no | temporary collections of data | can use the same consistent interface for data and easily bind data to a user interface |
In addition, it's possible to use a datasource other than a database, for example, a flat file, spreadsheet, or XML file. In this case, you would need to write custom code so a view object reads data from the datasource, and entity objects write data to the datasource.
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 and 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.
For example, the following figure shows a view object selecting from multiple entity objects. View objects named DeptEmp and EmpNames select data from the Emp entity object. DeptEmp also selects data from the Dept entity object.
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.
In the Application Module Wizard and Editor, you can choose the view links that you want to use to link view objects in master-detail relationships. 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, such as an unrestricted view and a detail view; you can specify aliases to represent the various usages of a given view object.
For example, the following figure shows an application module using a master-detail view (DeptView) and a top-level view (EmpView). 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. 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).
Business Components for Java automatically creates SQL queries for you in the design-time wizards. However, you can customize SQL queries as needed. If you need complete control over an entire query, you can define expert mode queries.
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.
You can use forward only mode in a view object to prevent data from entering the view cache. Using forward only mode can save memory resources and time, because only one view row is in memory at a time. Forward only mode is useful when you are fetching data and reading it once, such as formatting data for a web page, or for batch operations that proceed linearly. Note that if the view object is based on one or more entity objects, the data does pass to the entity cache in the normal manner, but no rows are added to the view cache.