SAP学习笔记 - 开发17 - 前端Fiori开发 Component 配置（组件化）-海口c网

上一章讲了Fiori前端开发中的国际化。

SAP学习笔记 - 开发16 - 前端Fiori开发 Properties文件（国际化），语言切换实例，Fiori 国际化（常用语言列表，关键规则，注意事项）-CSDN博客

本章继续讲Fiori开发的知识。

1，Component配置

1），Component.js

2），App.controller.js

3），index.js

2，Component配置（组件化）的理由/优势

2-1，集中化管理应用配置

a），优势

b），对比传统方式和组件化方式

2-2，全局资源生命周期管理

a），优势

b），对比传统方式和组件化方式

2-3，支持异步内容创建（Async Loading）

a），优势

b），对比传统方式和组件化方式

2-4，标准化应用结构

a），优势

b），典型结构

2-5，路由和导航集成

a），优势

b），对比传统方式和组件化方式

2-6，更好的可测试性

a），优势

2-7，何时不应使用 Component.js？

2-8，现代最佳实践

2-9，总结：组件化的核心价值

下面是详细内容。

1，Component配置

OpenUI5 SDK - Demo Kit

1），Component.js

这个文件里面的内容，可以理解为共通内容

在Fiori App加载的时候，最先加载，然后里面的数据在其他页面里面就可以直接用

从而实现不需要在每个页面里面取共通数据，而是可以直接使用的功能。

sap.ui.define(["sap/ui/core/UIComponent","sap/ui/model/json/JSONModel","sap/ui/model/resource/ResourceModel"
], (UIComponent, JSONModel, ResourceModel) => {"use strict";return UIComponent.extend("ui5.walkthrough.Component", {metadata : {"interfaces": ["sap.ui.core.IAsyncContentCreation"],"rootView": {"viewName": "ui5.walkthrough.view.App","type": "XML","id": "app"}},init() {// call the init function of the parentUIComponent.prototype.init.apply(this, arguments);// set data modelconst oData = {recipient : {name : "World"}};const oModel = new JSONModel(oData);this.setModel(oModel);// set i18n modelconst i18nModel = new ResourceModel({bundleName: "ui5.walkthrough.i18n.i18n"});this.setModel(i18nModel, "i18n");}});
});

看该文件的位置，在webapp 目录直下，表示是全局的文件

默认就生成了这些代码，咱们替换成上面代码

- rootView里面定义了默认View，以及该默认View的类型，ID等

"rootView": {
"viewName": "ui5.walkthrough.view.App",
"type": "XML",
"id": "app"
}

- init() { =》看这段代码是不是很熟悉，其实就是把下面这篇文章里用的init函数的内容给拿过来

这样，其他Controller.js 里面就不再需要写这种共通取数据代码，而是可以直接使用

SAP学习笔记 - 开发16 - 前端Fiori开发 Properties文件（国际化），语言切换实例，Fiori 国际化（常用语言列表，关键规则，注意事项）-CSDN博客

2），App.controller.js

init 中的共通内容给拿到Component.js 之后，App.controller.js 里面的内容就少了很多

这里可以直接取Model：i18n，因为Comonent.js 里面 setModel了

sap.ui.define(["sap/ui/core/mvc/Controller","sap/m/MessageToast"
], (Controller, MessageToast) => {"use strict";return Controller.extend("ui5.walkthrough.controller.App", {onShowHello() {// read msg from i18n modelconst oBundle = this.getView().getModel("i18n").getResourceBundle();const sRecipient = this.getView().getModel().getProperty("/recipient/name");const sMsg = oBundle.getText("helloMsg", [sRecipient]);// show messageMessageToast.show(sMsg);}});
});

3），index.js

原来是在index.js 里用XMLView，就是写成下面这样，现在换成 ComponentContainer

XMLView.create({
viewName: "ui5.walkthrough.view.App"
}).then((oView) => oView.placeAt("content"));

SAP学习笔记 - 开发15 - 前端Fiori开发 Boostrap，Controls，MVC(Model，View，Controller），Modules-CSDN博客

sap.ui.define(["sap/ui/core/ComponentContainer"
], (ComponentContainer) => {"use strict";new ComponentContainer({name: "ui5.walkthrough",settings : {id : "walkthrough"},async: true}).placeAt("content");
});

- name: "ui5.walkthrough", =》这实际上是在index.html 里指定的路径，即是Component.js 的路径

index.html里指定的ui5.walkthrough 是哪儿呢？就是 ./ ，还记得吧，也就是 index.html 当前路径

下面总体归纳一下Component配置（组件化）的理由及其优势。

以下内容为Deepseek中查询后整理而成。

2，Component配置（组件化）的理由/优势

将代码放到 Component.js 中是 SAPUI5 组件化开发（Component-based Development） 的核心实践，这种方式相比将所有逻辑放在控制器或视图中，具有以下显著优势：

2-1，集中化管理应用配置

a），优势

统一入口：Component.js 是 SAPUI5 应用的根节点，所有全局配置（路由、模型、服务等）在此声明，避免分散在多个文件中。
元数据集中：通过 metadata 属性定义应用结构（如默认根视图），框架会自动处理视图加载和生命周期。

metadata: {"rootView": {"viewName": "ui5.walkthrough.view.App", // 自动加载此视图"type": "XML"}
}

b），对比传统方式和组件化方式

❌ 传统方式：在 index.html 或控制器中硬编码视图加载逻辑。
✅ 组件化：通过声明式配置，框架自动处理。

2-2，全局资源生命周期管理

a），优势

模型共享：在 init 方法中创建的模型（如 JSONModel、i18n ResourceModel）会自动绑定到组件及其所有子视图，无需手动传递。

init() {this.setModel(new JSONModel(oData)); // 全局可用this.setModel(new ResourceModel(...), "i18n"); 
}

自动销毁：组件销毁时，框架会自动清理其创建的模型和资源，避免内存泄漏。

b），对比传统方式和组件化方式

❌ 传统方式：在每个控制器中重复初始化模型，需手动管理销毁。
✅ 组件化：一次初始化，全局复用。

2-3，支持异步内容创建（Async Loading）

a），优势

性能优化：通过 sap.ui.core.IAsyncContentCreation 接口声明组件支持异步加载，提升应用启动速度。

metadata: {"interfaces": ["sap.ui.core.IAsyncContentCreation"]
}

按需加载：视图和依赖资源仅在需要时加载，减少初始负载。

b），对比传统方式和组件化方式

❌ 传统方式：同步加载所有资源，阻塞渲染。
✅ 组件化：非阻塞式加载。

2-4，标准化应用结构

a），优势

一致性：符合 SAP Fiori 设计规范，便于团队协作和维护。
工具链支持：SAP Fiori Tools 和 IDE 插件（如 VS Code 扩展）能自动识别组件化结构，提供代码补全和验证。

b），典型结构

webapp/
├── Component.js       # 应用核心配置
├── manifest.json      # 描述应用元数据（现代推荐方式）
├── controller/
├── view/
└── i18n/

2-5，路由和导航集成

a），优势

集中路由配置：在组件中定义路由和目标视图，实现深层链接和书签功能。

metadata: {"routing": {"config": { /* 路由配置 */ },"routes": [ /* 路由规则 */ ]}
}

导航上下文：路由跳转时自动传递参数到目标视图。

b），对比传统方式和组件化方式

❌ 传统方式：需手动解析 URL 参数。
✅ 组件化：内置路由管理。

2-6，更好的可测试性

a），优势

隔离测试：组件可以独立于宿主环境（如 Fiori Launchpad）进行单元测试。
模拟数据：在测试中轻松替换组件模型。

2-7，何时不应使用 Component.js？

极简单应用：仅包含一个视图且无路由需求时，可直接用 XMLView.create()。
嵌入式控件：作为其他应用的部件（Widget）时，可能不需要完整组件。

2-8，现代最佳实践

在 SAPUI5 最新版本中，推荐将配置进一步迁移到 manifest.json 中，实现完全声明式开发：

{"sap.ui5": {"models": {"i18n": {"type": "sap.ui.model.resource.ResourceModel","settings": {"bundleName": "ui5.walkthrough.i18n.i18n"}}},"rootView": {"viewName": "ui5.walkthrough.view.App","type": "XML"}}
}

2-9，总结：组件化的核心价值

特性	传统方式缺点	组件化优势
配置管理	分散在多处，难维护	集中配置，一目了然
模型共享	需手动传递模型	自动注入，全局可用
生命周期	容易内存泄漏	自动清理资源
路由支持	需自定义实现	内置标准化路由
工具链支持	有限	完整 IDE 和调试工具支持