这个个性使得开发人员不仅能够在 Design time 时定义模型，而且能够在运行时定义模型。
用户不须要做任何额定的工作，因为 abap2UI5 在每个 AJAX 申请期间在后盾解决整个过程：
在应用程序中，咱们当初能够再次应用 RTTI，其形式与 ALV 的应用形式相似。这意味着无需为每个模型创立独自的应用程序。
下图是一个例子，其视图包含显示通用表的表输入，其类型在运行时创立和批改（相似于 SE16）：
同应用 RTTI 创立 Model 一样，ABAP2UI5 里的视图也反对 RTTI.
在 RAP 中，只能在运行时批改某些预约义的管制属性，而视图是在之前应用 UI 正文在 CDS 工件中定义的。然而，在 abap2UI5 应用程序中，能够动静替换整个视图控件。
例如，在以下利用中，表格控件被替换为列表控件，反之亦然：
上面是列表控件：
上面是表格控件：
最初，视图和模型的定义独立于 HTTP 服务，咱们不再被迫为每个应用程序提供预约义的动态 OData 服务，就像 RAP 中的状况一样。后端工件的数量显着缩小：
到目前为止，咱们察看到 abap2UI5 前端应用程序不晓得特定的应用程序，就像服务器上的通用 HTTP 服务一样，它也不晓得它正在传输的特定模型和视图。
这个概念惟一的非通用局部是实现接口 z2ui5_if_app 的用户应用程序：
在这种架构中，应用程序在创立视图和模型方面领有齐全的自在，但它也必须对其余所有承当全副责任。应用程序必须处理程序逻辑、应用程序状态，并记住它来自哪里以及下一步要去哪里。所有这所有都集中在这个繁多的应用程序层中。