Skip to Content

SAP UI5: One client side model with multiple paths or multiple models?

Hi all,

just wondering about your recommendations / best practices regarding the following:

I have a number of different types of client side data that my application needs to manage. To benefit from SAP UI5 data binding, I'm using the JSON model as store.

My question is, should I

1) Create a separate model for each type of data

2) Should I strive to minimize the number of models, and use different properties inside one model to structure my different types of data?

I figured that in terms of development, there is no real impact associated with either way. It doesn't make much difference if I have to manage many model names as opposed to managing many paths inside one model.

What I am not sure about is memory consumption and performance. I am assuming that creating a new model comes at the price of some overhead, and I am assuming that once a model is created, it doesn't cost a lot to have it manage multiple paths where data is stored.

But are these assumptions correct? And if so, how big is that overhead?

Very interested to hear your recommendations and opinions - thanks in advance!

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Jan 10, 2017 at 02:25 PM

    Roland,

    In my opinion, if the data is somewhat related I think you could manage it as multiple paths within the same model due to when you will need it in your application you will need to reference those models by name (hence the name, named models). also, when you will need this data from your controller, you will need to assign models to different variables and then you will need to use it with its different paths. i think you can minimize this by using the same model with different paths.

    If your data represents data that may not be related, such as, using the device model (to know whether or not an app is running on a phone/tablet/desktop, etc.. then you should keep it as separate named models.

    I have used 1-3 models and as you also observed I did not notice any drastic performance degradation. I hope this is helpful for your implementation.

    Add comment
    10|10000 characters needed characters exceeded

    • Hi Sergio, thanks for chiming in!

      > In my opinion, if the data is somewhat related

      It is always "somewhat related". It's needed by the same application :)
      Also, we can expresses the relationships between different data items by suggesting it in the path structure.

      > you will need it in your application you will need to reference those models by name (hence the name, named models)

      I know the term is used in the docs and tutorials, but conceptually, there is really no difference between "named" and "default" (unnamed) models.

      From the perspective of coding, one always needs to identify the model. Whether we do that by specifying its name, or by remembering that we need to obtain it by not passing a name, requires the same sort of effort. (On the grounds of the fact that I'd rather do the same task in the same way, I have taken to always explicitly naming my models anyway)
      Once we get a hold of the model, we always need to specify the path - even if that path happens to be "/"

      > Also, when you will need this data from your controller, you will need to assign models to different variables

      Can you clarify this? I usually do not assign models to controller members/properties. I either
      1) get a hold of the model by calling this.getView().getModel(<some model>)
      2) retrieve the model from a control or aggregation binding (this happens for example in control event handlers)

      Of course, once I have the model I do assign it to a local variable inside that method.

      > If your data represents data that may not be related, such as, using the device model (to know whether or not an app is running on a phone/tablet/desktop, etc.. then you should keep it as separate named models.

      Yes - device model and for example i18n model are part of the infrastructure and don't really handle application logic. So yes I would keep that separate from models holding application state. My question is about those application-specific data items - should those be in one or in multiple models.

      > I have used 1-3 models and as you also observed I did not notice any drastic performance degradation.

      Me neither, but I didn't exactly look for it.

  • Jan 10, 2017 at 11:03 PM

    yes in the assigning a model to a variable inside the controller - I probably said it wrong, but what I meant was the same thing you said along the lines of ...

    var model = this.getView().getModel(<some model>) ;// so you can minimize the use of variables here... i concur with you here.

    we probably need more opinions from others who have used different approaches, but I will guess that most developers skip the hassle to having many models... and instead minimize them to a single one.

    anyone else??

    Add comment
    10|10000 characters needed characters exceeded