导言

也许你在这个故事中认出了自己。你和几个同事已经为一个令人兴奋的新项目工作了几个月。开局不错，第一个发布的版本非常成功。现在这个概念已经被证明是有效的，需要更多的特性，代码库也在一天比一天增长。然而，进程正在放缓，因为它需要越来越多的时间来检查代码。奇怪的bug不断出现，手游返利，而且这些bug很难修复，因为理解代码似乎需要更多的时间。

这是软件开发中的一个典型问题，良好的体系结构可以在一定程度上缓解这个问题。也许你是幸运的，架构在一开始就被选中了（而且看起来也很合适）。然而，对于大多数（敏捷）项目来说，架构在开发过程中有点"浮现"。这通常是很好的，因为人们不能总是预测某个特定项目的最佳选择是什么。这并不是一个新的想法，但在UI5开发中，它似乎并不常见（除了Fiori启动板，它由许多组件组成）。尽管最近这个想法似乎得到了一些牵引力，在最近的版本中增加了支持。还有一些关于使用组件的文章，主要集中在路由部分。

基于组件开发的不同概念及其关系（来源：Leon van Ginneken）

拆分应用程序

基于组件开发的基本思想是将应用程序拆分为具有明确功能的各个部分。这些部分之间的依赖关系应该尽可能小。您也可以将这些部分称为"子应用程序"，但让我们继续使用术语"组件"。

使用组件的一些优点：

组件：

可以单独运行和测试，因此更易于开发。更易于在其他应用程序中重用。通过在组件上划分职责，使与大型团队甚至多个团队合作更容易。

在某种程度上，您可以将基于组件的开发视为将多个应用程序捆绑到一个包中。当然，最好的分离实际上是有多个应用程序，但在某些情况下这是不可取的。例如，当用户希望拥有一个应用程序，而不想一直切换到各种应用程序时。是的，云品，在某种程度上，Fiori Launchpad可以被视为一个基于组件的应用程序，但它也不总是希望与Launchpad一起工作（例如，当开发一个应该脱机工作的移动应用程序时）。

什么是组件？

我们需要就UI5技术上的组件达成一致。组件应该实现一个明确定义的API。换句话说，一个组件应该遵循一个特定的标准，否则就不可能构建通用的组件或者在项目之间轻松地共享组件。在UI5中，使用UI组件似乎很合适。在这里，您可以看到术语"组件"并不是突然出现的。

组件应该有一些严格的规则：

它涵盖了应用程序的明确功能。它可以自己运行。它对其他组件一无所知（这一个很重要！）。唯一的依赖关系是一组有限的"核心"模块（稍后将详细介绍）和一组有限的共享资源，如UI5库，自定义控件和一些实用程序库（如瞬间.js或mobx状态树）。

应用程序的其他部分

核心模块向组件提供通用功能，并应提供对外部API的抽象（例如调用端点加载数据时）。这增加了更容易测试的好处，因为您只需要将核心模块与测试模块互换，以模拟行为。

核心模块的示例：

Eventbus模块（用于在组件之间发送事件）日志模块（集中日志并将其批量发送到服务器）后端API模块（有一个模块负责从后端获取数据，并进行集中错误处理）

shell组件是用户开始使用的组件。原则上，它应该只负责集中路由和根视图中各种组件的放置。根组件中不应该有启动逻辑，因为规则是组件应该能够自己运行，而不应该依赖于根组件。对于这种逻辑，我们有apploader.

启动逻辑可以放在单独的"apploader"模块中。它不包含任何UI，这就是组件的用途。apploader负责注册组件名称空间并启动组件。任何组件都可以由apploader启动，而不仅仅是shell组件。因此，当测试一个单独的组件时，组件应该通过apploader启动。

也许你的项目似乎不需要apploader，什么是大数据云计算，但是在任何情况下实现它都是有用的，因为当需要启动逻辑时，大数据信息，你会有一个逻辑位置。

测试

端到端测试通常是一件痛苦的事，因为如果你想测试应用程序的某个子部分，你首先需要点击几个屏幕才能找到重要的部分。通过测试各种组件，你就是在测试你想测试的东西。

一旦你有了一个基于组件的架构设置，测试一个组件应该会容易得多。您可以模拟所有核心模块依赖项，因此只需测试组件。您可以使用uiveri5、opa5或任何其他测试框架。也许您确实需要一个单独的.html文件来启动测试，但是由于启动逻辑在apploader中，因此它不应该仅仅是一个包装器。

迁移到基于组件的体系结构