Skip to Content
Technical Articles

MVC(Model View Controller) in SAP UI5

Introduction: MVC architecture is one of the design patterns can be used in software development.The objective of this blog is to explain Model,View and Controller briefly.

Model View Controller(MVC) used to separate the representation of information(Data) from user actions.It allows to make changes independently.

  • View: Responsible for defining and rendering UI.
  • Model:Responsible for managing the application data.
  • Control:Used to control the data and view events.

Model:

Model in MVC holds the data  and provide methods for create,update,delete and read operation on the data.

There are 4 types of Models.

  • JSON Model (JavaScript Object Notation)
  • XML Model (Extensible markup language)
  • Resource Model
  • OData Model

In this JSON,XML,Resource Models are client side models and OData Model is server side model.

 

Client Side Model:

JSON Model XML Model Resource Model
  •  Client Side Model
  • Used for small

data set.

  • The data of the model  loaded completely          and available on the   client.
  •  Syntax:

var oModel = new sap.ui.model.

json.JSONModel();

  •  Can set the data to the model using setData() method.

Example:

oMode.setData({“name”:

”abcd”,age:”23”});

  • To set model to view

This.getView().

setModel(oModel);

  • Sorting and filtering will be applied in client side.
  • Supports oneway,two way and onetimebinding.
  • Default binding mode is Two way
  • Xml model allows

control to bind xml                data.

  • Client side model used for small data sets.
  •  The data of the model loaded completely and available on the client.
  • Syntax:

Var oModel = new sap.ui.model.xml.

XMLModel();

  • Can set  the data to model using setData() method.
  • Sorting and filtering will be applied in client side.
  • Supports one way,two way and one time binding.
  •  Default binding mode is Two way.

 

  •  Resource model is used  for  internationalization of      application.
  •  Is used as wrapper for resource bundles.
  •  In data binding we use the resource model          instance.
  •  It can be instantiated by using bundle name or bundle url.
  • Resource bundle file should ends with .properties extension.
  •  syntax:

Sap.ui.model.resource.

ResourceModel({bundleName:

”myBundle”,locale:”en”});

  • We can retrieve the bundle

by using bundle name.

var myBundle =oModel.getResourceBundle();

  • Supports Onetime binding.
  • Defalt binding mode is Onetime.

 

 

Server Side Model:

Odata Model
  •      Server side model, data will be available on server side. Client knows only visible or requested  data.
  •      Following 2 versions of oData Models are there.

1)sap.ui.model.odata.oDataModel –Deprecated since version 1.48.

2)sap.ui.model.odata.v2.oDataModel : Has improved features.Along with server side filtering and sorting it also provides client side sorting and filtering.

  •         Syntax for instantialting.

var serviceUrl = “your_url” ;

var oModel = sap.ui.model.odata.v2.oDataModel(serviceUrl);

·         When we instantiate the oData model a request will go for getting the metadata.

·         Supports Oneway,Twoway and Onetime binding.

·         Default binding mode is Oneway.

 

CRUD Operation:

OData model allows manual CRUD operations on the OData services.

Create:

Create function is used to trigger the post operation in OData.

Syntax:

OModel.create(“/EntitySetName”, OData,{ success:successHandler, 
error:errorHandler});

 

Where successHandler is executed on success of call and errorHandler is for handling the error.

OData will be our Payload.

 

Read:

The read function triggers the get request of the specified path.

Syntax:

Below syntax is used for requesting multiple records.

OModel.read(“/EntitySetName”,{ success:successHandler, error:errorHandler});

For getting single record the below syntax is used.where we pass the id.

OModel.read(“/EntitySetName(id)”,{ success:successHandler,
 error:errorHandler});

Update:

Update call triggers the PUT/MERGE request on ODATA.

Syntax:

 OModel.update(“/EntitySetName(id)”,payload,{ success:successHandler, 
error:errorHandler});

REMOVE:

Triggers the DELETE function in the ODATA.

OModel.remove(“/EntitySetName(id)”,{ success:successHandler, 
error:errorHandler});

VIEW:

View is responsible for defining and rendering UI.

SAP provides 4 predefined view types

  • JS View (JavaScript)
  • XML View
  • HTML View
  • JSON View

JavaScript View:

Extension  of JavaScript view is “view.js”.

It has 2 default methods for implementation.

  • getControllerName()
  • createContent()

getControllerName(): It specifies the controller belonging to this view.

sap.ui.jsview ("sap.hcm.Address", {
   getControllerName: function() {
      return "sap.hcm.Address.controller.js
   },

createContent(): This method used to create UI.Event handlers can be attached directly.

Example:

createContent: function(oController) {
      var oButton = new sap.m.Button({text:"Hello JS View"});
      oButton.attachPress(oController.handleButtonClicked);
      return oButton;
   }
  •  We cannot Hard code the Ids in JavaScript view.
  •  No parsing overhead.automatically managed.
  •  For uniqness we can give id using view.createId() method.

  Example:

 var oButton = new sap.m.Button(this.createId("myButton"),{text:"Hello"});
  •  No MVC structure.
  • Cannot embed  HTML elements.

HTML View:

File name ends with view.html.All view specific data can be added under <template>  tag.

We can create the controls using <div> tag.

Example:

<template data-controller-name="view.Example">
       <div data-sap-ui-type="sap.m.Page" data-title="Title">
              <div data-sap-ui-aggregation="content">
              </div>
       </div></template>

JSON View:

JSON view type defined in a file. Ends with view.json.

Example:

{ 
   "Type":"sap.ui.core.mvc.JSONView",
   "controllerName":"sap.hcm.Example",
   "content": [{
      "Type":"sap.m.Image",
      "id":"IdImage",
      "src":"http://www.sap.com/global/ui/images/global/sap-logo.png"
   },
   {
      "Type":"sap.ui.commons.Button",
      "id":"IdButton",
      "text":"Save"
   }]

}

XML VIEW:

This view will be defined in a file with extension view.xml.

XML views are preferred way to create views currently because of following reasons.

  • Can be validated automatically.
  • Easy to write and understand due to its hierarchical structure.

Example:

<mvc:View controllerName="sap.hcm.Address" xmlns="sap.m" xmlns:mvc="sap.ui.core.mvc">
   <Panel>
      <Image src="http://www.sap.com/global/ui/images/global/sap-logo.png"/>
      <Button text="Save"/>
   </Panel>	
</mvc:View>
  • We need to use name spaces for libraries used in XML view.
  • Best practice to use empty name space for “sap.m” library (xmlns=”sap .m”).

Controller:

  • View and Model logics are separated by using controllers.
  • Methods which are needed for data flow between model and view are implemented in the controllers.
  • Controller will be a JavaScript file with extension controller.js.

Controller Life Cycle:

SAPUI5 provides the following predefined  hook methods.

  • onInit(): This method will be called when view is instantiated. Will be called only once. You can write all your initial coding here i.e if you want to do some operation before first rendering of the view.
  • onBeforeRendering(): This method is invoked before the controller view is re-rendered.and not before the first rendering.
  • onAfterRendering():This method is invoked after view is rendered.If we want to do some post rendering operation then we can write code in this method.
  • onExit():This method will be invoked when view is destroyed. It can be used to free resources and finalize activities.

Along with all these hook methods a controller can contain additional methods for user actions.

Example:

sap.ui.controller("sap.hcm.Example", {
   onInit: function() {
      
   },
onBeforeRendering : function(){
},
onAfterRendering : function(){
},
onExit : function(){
},
onButtonPress : function(){
}
});

Conclusion:

MVC is an architecture or a software design pattern that makes creating huge applications easy and if we follow MVC design pattern it is easy for the developers to debug and make changes independently.

/
2 Comments
You must be Logged on to comment or reply to a post.
  • Good, short, and informative blog on the MVC pattern. Not sure if MVC is the design pattern to go when creating HUGE applications like you said tho, but when it comes to designing applications with an UI it’s a great way to separate concerns and keep the UI logic from the application logic.