SAPUI5 and Fiori Tools Part 1: MVC, Models, Views and Controllers
Learn SAPUI5 architecture in simple language: MVC, controls, models, data binding, components and the runtime flow of a typical Fiori application.
What this complete series covers
Learn SAPUI5 from MVC, models and binding through routing, OData, SAP Fiori tools, debugging, testing and deployment.
- Who it is for
- Best for SAP developers who want to build or support SAPUI5/Fiori applications beyond generated Fiori Elements.
- Prerequisites
- Basic JavaScript and web concepts help. Familiarity with OData is useful but not mandatory.
- Final outcome
- By the end, you should be able to build a structured SAPUI5 application, connect it to OData, navigate between views, debug it and use SAP Fiori tools productively.
- Part 1: SAPUI5 and Fiori Tools Part 1: MVC, Models, Views and Controllers
Understand the UI5 runtime, MVC and model-driven design.
- Part 2: SAPUI5 and Fiori Tools Part 2: Set Up BAS or VS Code and Generate an App
Set up Fiori tools and generate a production-shaped project.
- Part 3: SAPUI5 and Fiori Tools Part 3: Data Binding — JSON Model, OData Model, Modes
Use models and bindings correctly.
- Part 4: SAPUI5 and Fiori Tools Part 4: Routing, Navigation, Fragments and Dialogs
Build maintainable navigation and reusable dialogs.
- Part 5: SAPUI5 and Fiori Tools Part 5: OData V4 Read, Create, Update and Errors
Integrate CRUD operations with an OData V4 backend.
- Part 6: SAPUI5 and Fiori Tools Part 6: Debugging, Testing and Performance
Diagnose and tune UI5 applications using evidence.
- Part 7: SAPUI5 and Fiori Tools Part 7: Deployment to BTP and ABAP
Deploy and operate the application safely across environments.
System and release assumptions: SAPUI5, SAP Fiori tools, BAS and deployment options evolve. Validate exact CLI/generator options against the tool versions in your environment.
Explanation
📌 KEY POINTS
✅ Model = data, View = UI (XML), Controller = interaction logic.
✅ Component.js + manifest.json describe the app: models, routing, dependencies.
✅ Views bind to models declaratively; controllers should stay thin.
⚠️ Choose freestyle UI5 only when Fiori Elements cannot fulfil the requirement.
▶ SAPUI5 TUTORIAL: MVC, MODELS, VIEWS AND CONTROLLERS
━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS COMPLETE SERIES COVERS
- MVC and application architecture
- SAP Fiori tools setup and project generation
- Models and data binding
- Routing, navigation, fragments and dialogs
- OData V4 CRUD and backend integration
- Debugging, testing and performance
- Deployment and production lifecycle
━━━━━━━━━━━━━━━━━━━━
▶ WHY SAPUI5 STILL MATTERS
Fiori Elements is excellent when a metadata-driven floorplan fits the requirement. SAPUI5 is still important when you need a freestyle application, custom interaction, special visualization or deeper frontend control.
Do not choose freestyle UI5 simply because it feels more flexible. More custom UI code also means more code to test and maintain.
━━━━━━━━━━━━━━━━━━━━
▶ MVC IN ONE SENTENCE
Model holds data.
View describes UI.
Controller handles interaction and orchestration.
That separation makes a UI easier to understand and test.
━━━━━━━━━━━━━━━━━━━━
▶ COMPONENT AND MANIFEST
A modern SAPUI5 application normally has an application component and a manifest.
The manifest describes configuration such as:
- application ID;
- models/data sources;
- routing;
- dependencies;
- device/resource settings.
Keep configuration declarative where the framework supports it.
━━━━━━━━━━━━━━━━━━━━
▶ MODELS
Common concepts include:
- JSON model for local/client data;
- resource model for translated text;
- OData model for backend service data.
A model is not a database. It is the client-side abstraction used by controls and bindings.
━━━━━━━━━━━━━━━━━━━━
▶ DATA BINDING
Instead of manually copying values into every UI control, bind the UI to model paths.
Example concept:
┏━━ CODE ━━━━━━━━━━━━
┃ <Input value="{/customer/name}" />
┗━━━━━━━━━━━━━━━━━━━
When the model changes, binding keeps the UI synchronized according to the binding mode.
━━━━━━━━━━━━━━━━━━━━
▶ CONTROLS AND AGGREGATION
UI5 controls expose properties, events and aggregations.
For example, a table aggregates items. A page aggregates content. A button raises a press event.
Understand the control API instead of manipulating the DOM directly.
━━━━━━━━━━━━━━━━━━━━
▶ CONTROLLER RESPONSIBILITY
A controller should coordinate UI behavior, not become a 3,000-line business engine.
Good controller tasks:
- event handling;
- navigation;
- model orchestration;
- formatting delegation;
- calling reusable services.
Backend business validation should stay on the backend.
━━━━━━━━━━━━━━━━━━━━
▶ CHECKPOINT
You should be able to explain the runtime path:
Component → manifest → model → view binding → controller event → service/backend
━━━━━━━━━━━━━━━━━━━━
▶ COMMON MISTAKES
- Writing all logic in one controller.
- Manipulating HTML DOM directly.
- Hard-coding texts instead of i18n.
- Choosing freestyle UI5 when Fiori Elements already fits.
- Duplicating backend business rules in JavaScript.
━━━━━━━━━━━━━━━━━━━━
▶ INTERVIEW TAKEAWAY
“SAPUI5 is a component-based JavaScript UI framework. I structure freestyle apps with manifest-driven configuration, MVC, models and declarative data binding. Controllers orchestrate UI behavior, while authoritative business rules remain in backend services.”
Code example
// ===== Component.js - the app entry point =====sap.ui.define(["sap/ui/core/UIComponent"], function (UIComponent) { "use strict"; return UIComponent.extend("zpurchreq.Component", { metadata: { manifest: "json" }, // configuration comes from manifest.json init: function () { UIComponent.prototype.init.apply(this, arguments); this.getRouter().initialize(); // start routing (Part 4) } });}); // ===== manifest.json (excerpt) =====// "sap.app": { "id": "zpurchreq", "i18n": "i18n/i18n.properties", ... }// "sap.ui5": { "rootView": { "viewName": "zpurchreq.view.App", "type": "XML" },// "models": { "i18n": { "type": "sap.ui.model.resource.ResourceModel",// "settings": { "bundleName": "zpurchreq.i18n.i18n" } } } } <!-- ===== view/Main.view.xml - the View (UI only) ===== --><mvc:View controllerName="zpurchreq.controller.Main" xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m"> <Page title="{i18n>appTitle}"> <Input value="{/request/description}" placeholder="{i18n>description}" /> <Button text="{i18n>save}" type="Emphasized" press=".onSave" /> </Page></mvc:View> // ===== controller/Main.controller.js - the Controller (interaction) =====sap.ui.define(["sap/ui/core/mvc/Controller", "sap/ui/model/json/JSONModel", "sap/m/MessageToast"], function (Controller, JSONModel, MessageToast) { "use strict"; return Controller.extend("zpurchreq.controller.Main", { onInit: function () { // the Model: data for this view this.getView().setModel(new JSONModel({ request: { description: "" } })); }, onSave: function () { const sText = this.getView().getModel().getProperty("/request/description"); MessageToast.show("Saved: " + sText); // real apps save via the OData model (Part 5) } });}); # ===== i18n/i18n.properties =====# appTitle=Purchase Requests# description=Description# save=SaveReal project scenario
A team builds a custom order app with all data and validation logic inside one controller. Every change breaks unrelated behavior. Refactoring models, reusable services and backend validation makes the application maintainable.
Common mistakes
- Giant controllers.
- Direct DOM manipulation.
- Hard-coded UI text.
- Frontend-only business validation.
Best practices
- Keep controllers thin.
- Use manifest configuration.
- Use i18n.
- Prefer declarative binding.
- Keep business rules in backend domain services.
Interview angle
Explain MVC, manifest.json, model types and why binding is preferred over manually setting control values.
Practice this lesson
Quick check
1. What is the main purpose of manifest.json in a SAPUI5 app?
2. Which practice makes a freestyle SAPUI5 app hard to maintain?
3. In SAPUI5 MVC, where should the event handler for a Save button be implemented?
Interview questions
1. Explain MVC in SAPUI5 and the role of Component.js and manifest.json.
Answer it in your own words first, then compare.
2. A freestyle app has 2,000-line controllers mixing UI, data and business logic. How do you restructure it?
Answer it in your own words first, then compare.
Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.
More lessons in this topic
- SAPUI5 and Fiori Tools Part 2: Set Up BAS or VS Code and Generate an App
- SAPUI5 and Fiori Tools Part 3: Data Binding — JSON Model, OData Model, Modes
- SAPUI5 and Fiori Tools Part 4: Routing, Navigation, Fragments and Dialogs
- SAPUI5 and Fiori Tools Part 5: OData V4 Read, Create, Update and Errors
- SAPUI5 and Fiori Tools Part 6: Debugging, Testing and Performance
- SAPUI5 and Fiori Tools Part 7: Deployment to BTP and ABAP