Read Only View Objects vs Non Update-able Entities

[BradW]

I have a quick question for the team.  In the ADF Code Guidelines, it states the following:

[ADFcg1-02041] – Avoid read only view objects for speed benefits alone - Older ADF manuals 

recommended using read only view objects as there was a minor speed benefit. Since JDeveloper 11g this 

is no longer true as the caching mechanism has been improved. Today read only view objects should be 

reserved for complex queries such as those with set operations (e.g. UNION, MINUS, INTERSECT) 

and connect by queries. All other view objects should be based on entity objects. If the view object 

needs to be read only, unselect the "Updateable" property when the entity object is mapped to view 

objects.

I have a dashboard where we need to show lots of summary patient information.  I am leaning towards ReadOnly view objects as I am thinking there would be a smaller memory footprint as entities/rows typically take up memory in a cache.

Is my assumption about entities taking up memory as part of a cache correct?  Do readonly view objects also have a cache?

Anyways, I am keen on understanding why Entity objects should be used or whether it makes sense to use read only view objects in this scenario.

Thanks,

BradW

[Florin Marcus]

Hi Brad,

The preference for Entity based View Objects is less related with runtime behaviour and more about development process effectiveness: higher reusability (since you can share EO elements like labels, formatting, using Declarative View Objects etc). But when focusing on runtime behaviour alone, indeed, the memory footprint is a bit higher, as reported by JDeveloper Memory Profiler:

To test this, I have created a simple Model project, running two view objects against HR schema's EMPLOYEES table - one SQL-based and one EO-based (non-updateable).

Both VOs would fire the same query against the database. Furthermore, I was using JDeveloper Memory Profiler when running the following scenario:

1. Start the Application Module from BC Tester.

2. Query one of the two VO's, by showing multiple records (Right-click -> Show Table).

Memory Profiler showed that when running the SQL-Based View Object in BC Tester,  the memory footprint is 11.4 MB, while running the EO-Based (non-updateable) View Object, the memory consumption was of 11.6 MB, a bit higher. 

Nevertheless, I wouldn't go that far and say that a slightly smaller memory footprint is an argument for using SQL-based queries. Following this logic, it would mean that we should prefer running Servlets over JDBC over any Java Web framework, or even question the use of Java for building applications, since C++ would be a more effective solution in terms of memory consumption.

Hope this helps,

Florin Marcus

www.redsamuraiconsulting.com

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
 
---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[SHAY SHMELTZER]

One more thing to add about the benefits of having an EO based VO is that you can switch your VO to be in declarative mode. This can further reduce your memory and network usage.
If you are not familiar with the declarative VO - check out this quick demo:
https://blogs.oracle.com/shay/entry/declarative_view_objects_vos_for

That being said for dashboards and queries that use group function sometime there is no escaping the usage of query only VO.
A VO that uses a SUM function would be preferable to fetching all the records to the middletier and doing the SUM at the BC layer.

Shay

On 7/19/2013 12:52 PM, Florin Marcus wrote:

Hi Brad,

The preference for Entity based View Objects is less related with runtime behaviour and more about development process effectiveness: higher reusability (since you can share EO elements like labels, formatting, using Declarative View Objects etc). But when focusing on runtime�behaviour�alone, indeed, the memory footprint is a bit higher, as reported by JDeveloper Memory Profiler:

To test this, I have created a simple Model project, running two view objects against HR schema's EMPLOYEES table - one SQL-based and one EO-based (non-updateable).

Both VOs would fire the same query against the database. Furthermore, I was using JDeveloper Memory Profiler when running the following scenario:

1. Start the Application Module from BC Tester.

2. Query one of the two VO's, by showing multiple records (Right-click -> Show Table).

Memory Profiler showed that when running the SQL-Based View Object in BC Tester, �the memory footprint is 11.4 MB, while running the EO-Based (non-updateable) View Object, the memory consumption was of 11.6 MB, a bit higher.�

Nevertheless, I wouldn't go that far and say that a slightly smaller memory footprint is an argument for using SQL-based queries. Following this logic, it would mean that we should prefer running Servlets over JDBC over any Java Web framework, or even question the use of Java for building applications, since C++ would be a more effective solution in terms of memory consumption.

Hope this helps,

Florin Marcus

www.redsamuraiconsulting.com

On Fri, Jul 19, 2013 at 1:40 AM, BradW <bwor...@gmail.com> wrote:

I have a quick question for the team. �In the ADF Code Guidelines, it states the following:

[ADFcg1-02041] � Avoid read only view objects for speed benefits alone - Older ADF manuals�

recommended using read only view objects as there was a minor speed benefit. Since JDeveloper 11g this�

is no longer true as the caching mechanism has been improved. Today read only view objects should be�

reserved for complex queries such as those with set operations (e.g. UNION, MINUS, INTERSECT)�

and connect by queries. All other view objects should be based on entity objects. If the view object�

needs to be read only, unselect the "Updateable" property when the entity object is mapped to view�

objects.

I have a dashboard where we need to show lots of summary patient information. �I am leaning towards ReadOnly view objects as I am thinking there would be a smaller memory footprint as entities/rows typically take up memory in a cache.

Is my assumption about entities taking up memory as part of a cache correct? �Do readonly view objects also have a cache?

Anyways, I am keen on understanding why Entity objects should be used or whether it makes sense to use read only view objects in this scenario.

Thanks,

BradW

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com

�

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

�

---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

�
�

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com

�

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

�

---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

�
�