Read only View Object should *also* be based on Entities

This might involve a wee bit of paradigm shift for developers moving on from 10g. 
The prevailing wisdom in 10g has been to not base read-only view objects on Entities and for good reason: performance gain. 

The recommended approach in the Fusion developer guide, however, is to base all view objects on Entities - a fact that might have gone unnoticed, especially in projects newly migrating over from 10g. 

While no measurable metrics seem to be available for 10g, the Fusion developer guide (Section 39.2.2) mentions that 
"there is no significant performance degradation incurred by using the entity object to create the local cache"

Not just that, for entity based view objects, "The data in the view object will reflect the state of the local cache rather than need to return to the database for each read operation"
This is something that ANY object-relational mapping/persistence technology should have built in - so does ADFbc, with its entity and view caches. 

While any Entity usage can be marked as 'non updatable' in the VO (as discussed in the dev guide section referenced above), in 11g, there is an additional EO level property that allows you to mark the whole Entity as non-updatable. 

Possible usecases might be:
- A way of enforcing read-only access to certain data, say, in a shared service or ADFbc library.

To sum up some of the benefits of having your read-only view objects to be entity based:
1. Declarative SQL generation.
2. Reuse of common properties (like attribute hints, labels etc.) across different views of data, enforcing consistency (unless some views explicitly have to display something differently, they get to just reuse the EO properties) 
3. Additional overhead of maintaining the view-entity coordination is minimal, and possibly overshadowed by performance gains from local caching. (an expert-mode VO would need to return to DB for each read operation)


Chris Muir said…
Nice post Jang with thanks.

John Flack said…
I thought that VOs have their own cache, and don't depend on an EO to cache data. Some of my read-only VOs are based on read-only database objects, like non-updatable views, or SELECT FROM TABLE(function_returning_table). Some SHOULD be re-queried every time they are used, because the underlying data changes frequently.
Many thanks, John and Chris.
I really have no valid excuse for not responding earlier.
The example you've mentioned is surely not declaratively achievable (like the other cases listed in the developer guide that need expert mode hand-coded SQL)

On the caches, I fould this informative list by Chris:

Popular posts from this blog

Recursive calls in Oracle Integration Flows (Scenario: Paginated API calls for large Data Sets)

How to show/hide operators in adf:query advanced mode

WS Security - enabling passwordDigest authentication in an Oracle FMW environment