Explain SAPUI5 Fundamentals & MVC Architecture in SAP

59 / 65

BTPbeginner

SAPUI5 Fundamentals & MVC Architecture

The core JavaScript framework underlying Fiori apps - views, controllers, models, and data binding.

SAPUI5 is the JavaScript framework Fiori is built on. Fiori Elements generates UI5 apps; when a requirement outgrows the templates, you write UI5 by hand.

SAPUI5's data binding is like a live shared whiteboard where erasing and rewriting one copy (the model) instantly updates every other linked screen (view controls) showing the same information, rather than manually walking around updating each separate whiteboard by hand every time something changes.

Key Concepts

Model, view, controller, and one idea that carries the rest.

    view        XML declaring the UI from the control library
    controller  JavaScript: event handlers and lifecycle hooks
    model       the data, bound to the controls

    <Table items="{/Orders}">
      <ColumnListItem>
        <Text text="{customer}"/>
        <Text text="{amount}"/>
      </ColumnListItem>
    </Table>

Data binding is the idea. The table is bound to /Orders in the model, and each row binds its fields. Change the model and the table updates. There is no code that adds rows and no DOM manipulation.

/Orders

Model types, for different jobs.

    JSON model      client-side state -- a filter setting, a flag
    OData model     the backend service. Handles batching, $expand,
                    and create/update/delete against it.
    Resource model  i18n text bundles, so labels are translatable

One-way against two-way binding. One-way: model changes update the view. Two-way: an edited input writes back to the model automatically.

Editable forms need two-way. Display-only screens should not use it, because it makes accidental modification possible and costs change tracking for nothing.

Controller lifecycle hooks.

    onInit              once, when the controller is created
    onBeforeRendering   before each render
    onAfterRendering    after -- where DOM-dependent work belongs

The manifest is more important than it looks. manifest.json declares routing, models, dependencies and the app's descriptor — declaratively, not in code.

manifest.json

That matters because tooling and the Fiori Launchpad read it without executing the application. An app's structure is inspectable, which is how the Launchpad knows what it is launching.

Fragments avoid duplicated markup. A dialog or a reusable block lives in its own XML fragment and is loaded where needed, instead of being repeated across views. Any application beyond a couple of screens ends up needing them.

When to write UI5 by hand at all. Fiori Elements handles the standard shapes and gives you every Fiori pattern free. Reach for freestyle UI5 when the interaction genuinely does not fit one — a planning board, a configurator, a graphical editor — because from then on every element is yours to maintain.

What the interviewer is probing.1. "How does two-way binding work in UI5?" Probing: the mechanism. Stalls: "Automatically." Moves up: the model holds data, the view binds to paths, and changes propagate both ways — which is why you change the model, not the control.

2. "What model types would you use and when?" Probing: the breadth. Stalls: "JSON." *Moves up:* OData for backend data, JSON for local view state, and resource models for texts.

3. "Why are fragments useful?" Probing: the structure. Stalls: "Reuse." Moves up: reusable UI pieces without their own controller, which is how dialogs and repeated form sections stay maintainable.

4. "What is the manifest for?" Probing: the descriptor. Stalls: "Configuration." Moves up: declaring data sources, models, routing and dependencies, so the app is configured rather than wired in code.