What benefits do I get from using ODataModel vs. JSONModel?

Question

I'm reading data from HANA using a JSONModel and simply passing in the URL to the source and retrieving it as in the following:

var data = new sap.ui.model.json.JSONModel(urlPath);

Then I can bind it to my view: this.getView().setModel(data);

I have also seen the following way of doing it, where an ODataModel is created and then the JSONModel is created from the data.

var oModel = new sap.ui.model.odata.ODataModel(urlPath);

oModelJson = new sap.ui.model.json.JSONModel();
oModel.read("/Items",
            null,
            ["$filter=ImItems eq 'imputParameter'"],
            null,
            function(oData, oResponse) {
                oModelJson.setData(oData);
            },
            null
);

What difference is there in creating the ODataModel first than creating the JSONModel at once. So assuming I'm getting back from the database about 5,000 data points, which approach should I use, or would there be no difference?

Answer 1

JSONModel is a Client model to get the data and set data to the view for JSON format.

ODataModel is a model implementation for OData protocol. This allows CRUD operations on the OData entities. JSONModel doesn't support Create/Update/Delete/Batch operations.

So coming to your scenario, I would suggest to use ODataModel always to do CRUD operations (inclusive of read). Then can use JSON model to bind the data to view.

Note that it's better to have one ODataModel per app and multiple JSONModels bound to views.

Consider using ODataModel V2 and since you have mentioned that you are dealing with 5K data points, if you don't all the data in the UI. Use setSizeLimit to make sure you have set proper upper bound.

Answer 2

One major difference between both of them is:

A lot of controls in SAPUI5 for instance, smarttable, bind automatically to the odata entities, meaning it dynamically creates the columns and the tuples based on the Odata metadata XML file. In this scenario, you cannot use a JSON Model.

IMHO, I would go with OData because of this "automatic binding" that a lot of components SAPUI5 have. But, I also ran into scenarios when the OData entities were not structured well, meaning the "automatic binding" that some SAP UI components had, did not work as expected.

In those scenarios, I had to get the JSON out of the OData, created/destroyed a few properties and then I did the bind to the mentioned SAP UI component.

Answer 3

Both models can be used without conflict. In fact, most applications will use both.

You want to use the OData model to send/retrieve data from the server. The OData model will handle building the URLs for you. For instance, if you want to filter, sort, or use paging in your data without the OData model, you will need to build the URL yourself.

yourUrl.com/EntitySet?$filter eq Property1='Value'&$sort= ..... &top=... etc.

This will be difficult without the OData model, and makes the application more difficult to maintain and debug. Let the OData model do that for you:

ODataModel.read("/EntitySet, {
    filters: [new Filter("Property1", "EQ", "Value")]
});

The greatest benefit of the OData model in my opinion, though, is binding directly from the XML views.

<List items="{/EntitySet}">
    <items>
        <StandardListItem title="{objectTitle}"/>
    </items>
</List>

This will automatically call the backend, retrieve the data from the entity set, and bind it to the list. No need to construct any URLs, make any calls, etc.

Using a JSON model to retrieve the data from an OData service will only make things more difficult than they have to be.

But... that being said... the JSON model is a very powerful tool. You can use it to store configuration data or any data you want to hold in the UI and manipulate. You can use the JSON model as sort of a mini-database in your application that can pass data globally across your application.

To summarize, you should use the OData model to get/send data. You should use the JSON model for local data storage. There will not be conflicts trying to use both.