这个特性使得开发人员不仅可以在 Design time 时定义模型，而且可以在运行时定义模型。
用户不需要做任何额外的工作，因为 abap2UI5 在每个 AJAX 请求期间在后台处理整个过程：
在应用程序中，我们现在可以再次使用 RTTI，其方式与 ALV 的使用方式类似。这意味着无需为每个模型创建单独的应用程序。
下图是一个例子，其视图包括显示通用表的表输出，其类型在运行时创建和修改（类似于 SE16）：
同使用 RTTI 创建 Model 一样，ABAP2UI5里的视图也支持 RTTI.
在 RAP 中，只能在运行时修改某些预定义的控制属性，而视图是在之前使用 UI 注释在 CDS 工件中定义的。 但是，在 abap2UI5 应用程序中，可以动态替换整个视图控件。
例如，在以下应用中，表格控件被替换为列表控件，反之亦然：
下面是列表控件：
下面是表格控件：
最后，视图和模型的定义独立于 HTTP 服务，我们不再被迫为每个应用程序提供预定义的静态 OData 服务，就像 RAP 中的情况一样。 后端工件的数量显着减少：
到目前为止，我们观察到abap2UI5前端应用程序不知道特定的应用程序，就像服务器上的通用HTTP服务一样，它也不知道它正在传输的特定模型和视图。
这个概念唯一的非通用部分是实现接口 z2ui5_if_app 的用户应用程序：
在这种架构中，应用程序在创建视图和模型方面拥有完全的自由，但它也必须对其他一切承担全部责任。 应用程序必须处理程序逻辑、应用程序状态，并记住它来自哪里以及下一步要去哪里。 所有这一切都集中在这个单一的应用程序层中。