当某人使用基于ABAP代码的实现时，该实现通常是指DPC_EXT类而不是MPC_EXT类的实现。

尽管从技术上讲可以在ABAP代码中实现注释，但我不建议这样做，强烈建议在CDS视图中使用注释，并使用引用的数据源方法（从750开始）。

如果您正在使用不支持在CDS视图中使用注释的SAP NetWeaver 740，或者甚至在仅基于代码的实现可用的旧版本中使用SAP NetWeaver 740，则SAP Web IDE中的注释建模器将是注释OData的更好工具。 没有注释的服务，而不是在MPC_EXT中使用基于代码的注释实现。

但是您可以看到，我已经提出了一个措辞，其中根本不使用"应用程序逻辑"一词。

"应用程序的服务实现（ABAP和/或DDL源）在BES中"。

因此，我建议将其改写为 我们只是在谈论BES中应用程序所使用的服务实现这一事实。

在SAP方面，我们经常谈论SAP Fiori应用程序，我们指的是SAPUI5方面的实现和 在SAP后端的实现，因为两者都是捆绑提供的。

所以我们可以谈谈"在SAPUI5中实现的应用逻辑"。 但这意味着我们必须在UX100的脚本中添加一个或另一个句子。 ;-）

我知道，这里有很多可能性，因此通常很难定义某物的位置和位置。 基于ABAP创建注释的可能性只是为了支持您的观点，即只要有人使用读取这些注释的Fiori Elements，就可以通过abap定义UI（对于我来说，Fiori App）。 当然，可以使用更简单的方法来注释，例如丰富CDS-View或在WEB IDE中使用注释文件"向导"，或者仅在手动创建的文件中提供它们。 我同意以您认为的方式改写句子将是一种解决方案，或者说是更正确的。

您好，Aleks，

我可以与培训部门的同事联系，但我不认为这种说法是最卖座的。

< p>我们可能会重新定义该语句，但是由于我不了解文本的完整上下文。

只读取这样的语句，我宁愿写成"服务实现（ABAP和/或DDL源代码） 的应用程序位于BES中"。 （BES是我们课程中使用的后端系统的衍生产品。）

基于集线器的部署只是一个罕见的案例，很少使用，myInbox的TaskGateway服务是我想到的唯一示例

因此，我们正在谈论基于集线器的和嵌入式部署方案。 在后一种情况下，系统同时具有Hub和BES的角色，因此上面的陈述是正确的。

并且确实，大多数业务逻辑都驻留在OData服务实现中（以防万一） Fiori Elements的使用率甚至是100％）。 因此，我完全同意诸如"应用程序的逻辑在BES中"之类的声明。

最诚挚的问候，

Andre

你好 安德烈，

感谢您的回复。 我同意，这不是必需的演出塞子，但是可以。 如果您正在MPC_EXT-Define中使用基于ABAP代码的注释实现，那么就Fiori-Elements-Apps而言，您是正确的，就像在句子中"在ABAP中声明"那样。 但是，如果不是"应用程序逻辑"，那么对于SAPUI5-Apps，如何命名用JavaScript实现的逻辑呢？ 在这句话中，它不被称为"业务逻辑"，正如您（还有我）所说的那样，而只是"应用程序的逻辑"->我对此的第一个关联是控制器文件中的编码。

但是无论如何，感谢您的答复并将其带给您的同事！

最好的问候，

亚历山大