About Fiori UI5 Application

SAP UI5 applications are built using the MVC architecture, where responsibilities are divided among Model, View, and Controller.
The View defines the UI using XML, the Controller handles application logic and user interactions, and the Model manages the application data.
This separation of concerns ensures that the code remains clean, reusable, and easy to maintain.
Moreover, UI5 provides powerful data binding between the Model and the View, enabling automatic UI updates without requiring manual intervention.

For UI5 Application File Structure, usage and flow of execution, use -

Types of Data Model

1. Resource Model(sap.ui.model.resource.ResourceModel)

The Resource Model is used in SAP Fiori UI5 to handle text translations (internationalization - i18n).
Instead of hardcoding text in UI, we can store them in a properties file (i18n.properties), and UI dynamically loads the correct language.
Its main purpose is it provide Multi-language support which can be implemented by creating multiple i18n file based on different country language like - i18n_hi.properties (for Hindi), i18n_de.properties (for German), i18n_ja.properties (for Japanese), etc..
It is also called Client Side Model as data is stored in the browser (frontend).

2. JSON Model (sap.ui.model.json.JSONModel)

It is used to stores data in JSON format (key-value pairs) and is mostly used.
It is fast, easy to use for small apps but Not suitable for large backend data.
It is also called Client Side Model as data is stored in the browser (frontend).

3. OData Model

OData Service (Open Data Protocol Service) is a REST-based web service used to exchange data between client and server in a standardized way.
An OData service allows applications (like SAP Fiori apps) to read, create, update, and delete data over HTTP using standard methods.
It is of 2 Types - oData v2 and oData v4 where oData v2 is widely used OData model in SAP UI5 which is version 2 protocol and is supported in almost all SAP systems while oData v4 is New and advanced version of OData, designed for better performance and cleaner architecture.
It is also called Server Side Model as data comes from backend server via API/odata service.

4. XML Model

The XML Model is used to manage data in XML format inside a UI5 application.
Data is structured using XML tags.
It is also called Client Side Model as data is stored in the browser (frontend).

Architecture of Fiori UI5 View

1. Object (Root Class)

Object is the root base class in SAP UI5 that provides object-oriented features like inheritance, lifecycle management, and class extension.
All UI5 elements and controls ultimately inherit from this class.

2. Element (Base Class)

Element is the base class for most UI5 objects.
It provides basic features like:- ID handling, Event handling, Data binding support, but does NOT render UI directly.

3. Control (UI Component)

Control extends Element(Base Class) and is responsible for UI rendering.
It renders visible UI, has properties, aggregations, events and used inside XML Views.

4. Aggregation (Aggregate)

Aggregation defines parent-child relationship between controls.
It renders visible UI, has properties, aggregations, events and used inside XML Views.

5. Property

A property is a value that defines the state or appearance of a Control.
It is used to manage- Text content, Visibility, Color, size, etc..

6. Event

Event is a mechanism through which a Control notifies the application when a user interaction or action occurs.
Event manages or handle:- User Click, Any Change, User Input, Selection, etc..

Code Example -

View1.view.xml

<Page>
	<content>
    <Button text="This is an example Text Statement" press="onClick" />
    
    <Select>
        <items>
            <core:Item key="1" text="Option 1" />
            <core:Item key="2" text="Option 2" />
        </items>
    </Select>

	</content>
</Page>

On the above code snippet -

Page - Control
content - Aggregation
Button - Control
text - Property
press - Event
Select - Control
items - Aggregation
Item - Element (not Control because it is not directly rendered, instead Select gets rendered in UI)

What is Data Binding ..?

Data Binding connects your UI (View) with data (Model). It keeps UI and data in sync automatically.

Types of Binding

1. Property Binding (One Value Binding)

It is used to bind a single value (like text, title, visibility, etc.) in the form of Text, Input, etc.

Sample Data Example -

model/Data.json

{
    "employeeName": "User1"
}

2. Element Binding (Context Binding)

It is used when we wants to bind an object content from the data in Form, Details, etc.
Like you wants to bind the below object data -

Sample Data Example -

model/Data.json

{
    "employee" : {
        "name": "User1",
        "role": "Developer"
    }
}

3. Aggregation Binding (List Binding)

It is used when we wants to bind multiple records (array/list of objects) from the data in Table, List, etc.
Like you wants to bind the below array of object data -

Sample Data Example -

model/Data.json

{
    "employees" : [
        {
            "name": "User1",
            "role": "Developer"
        },
        {
            "name": "User2",
            "role": "Admin"
        },
        {
            "name": "User3",
            "role": "Viewer"
        }
    ]
}

4. Expression Binding

Expression Binding is writing small logic (conditions or calculations) directly inside the XML view.
It changes UI dynamically based on data.

For Example change the view based on rating value -

model/Data.json

{
    "employees" : [
        {
            "name": "User1",
            "role": "Developer",
            "rating": 3
        },
        {
            "name": "User2",
            "role": "Admin",
            "rating": 4
        },
        {
            "name": "User3",
            "role": "Viewer",
            "rating": 2
        }
    ]
}

Type of Data Binding based on Data Flow

1. One Time Binding

In this way of binding, data flows from model to UI only once.
Once data is set on UI, no further update happens.
Example - Binding Resource Model with UI

2. One-Way Binding

In this way of binding, data flows only from Model to View.
UI gets updated when model changes.
User changes in UI do NOT update model.
Example - Display Data on Text, labels, read-only fields using Property, Element or Aggregation Binding.

3. Two-Way Binding

In this way of binding, data flows from Model to View and from View to Model.
Model updates UI and UI updates Model.
User changes in UI updates model data.
Example - Display and Read Data from Forms or Input Fields using Property, Element or Aggregation Binding.