Performance Aspects

The OData V4 model uses an odata.metadata=minimal header in its requests to reduce the amount of data which is sent from server to client. For more information, see section "3.1.1 odata.metadata=minimal" in the OData JSON Format Version 4.0 specification.

An application can either specify $expand and $select parameters to read all data to be displayed in one request, or create bindings dynamically to load only part of the data with one request per binding. The application needs to decide whether to have less roundtrips with more payload or more roundtrips with smaller payload.

To reduce payload, applications should only select properties that are needed using $select (see the code sample in the Parameters section under Bindings). Besides the properties needed on the UI, the binding must select key properties to support features such as read requests sent from a child binding, write requests, or bound operations on the respective entity.

By default, the OData V4 model collects all requests made to the OData service in a batch request to reduce the number of roundtrips. The disadvantage of a batch request is that it cannot be cached by the browser. If some of the requests (e.g. value help requests) are "cacheable", it is a good idea to request these resources directly and use the browser cache to improve the performance of the application. In such cases, use the $direct group as described in the section Batch Control.

Absolute bindings and also relative bindings which fulfill certain conditions have a cache which is used for their data. Once data is read, all value requests (e.g. those made by dependent relative bindings) are served by this cached data. ODataListBinding additionally supports paging. For more information about this, see Bindings.

Calling refresh on an absolute binding clears its cache as well as the caches of its relative child bindings. Calling refresh on the model refreshes all bindings that have been created by that model.