上一章讲了Fiori前端开发中的国际化。
SAP学习笔记 - 开发16 - 前端Fiori开发 Properties文件（国际化） ，语言切换实例，Fiori 国际化（常用语言列表，关键规则，注意事项）-CSDN博客
本章继续讲Fiori开发的知识。
目录
下面是详细内容。
1，Component配置
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 parent
UIComponent.prototype.init.apply(this, arguments);
// set data model
const oData = {
recipient : {
name : "World"
}
};
const oModel = new JSONModel(oData);
this.setModel(oModel);
// set i18n model
const 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 model
const oBundle = this.getView().getModel("i18n").getResourceBundle();
const sRecipient = this.getView().getModel().getProperty("/recipient/name");
const sMsg = oBundle.getText("helloMsg", [sRecipient]);
// show message
MessageToast.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 和调试工具支持 |
通过组件化设计，SAPUI5 应用能获得更好的可维护性、性能和扩展性，这是企业级 Fiori 应用的必备架构模式。
确实放到Component.js里面之后好像好处巨大哈。
咱们可能没有想这么多，SAP怎么定咱们怎么用，只是Controller.js里面代码少了确实是个好事。
现在更方便的是，都已经可以吧这个东西给放到manifest.json里面来了，这就有点儿像配置了哈。所以咱们也去理解理解上面说的这些条目的含义，给我们启发，而且也许客户就喜欢听这个呢😄
以上就是本篇的全部内容。
更多SAP顾问业务知识请点击下面目录链接或东京老树根的博客主页