我如何为a建模;选择、映射、保存到本地文件;用ABAPOO报告?

我如何为a建模;选择、映射、保存到本地文件;用ABAPOO报告?,abap,Abap,报告需要根据选择屏幕输入选择主数据,将所需字段映射到新的导出结构,转换为XML并保存到本地文件 由于有多个报表针对不同类型的主数据执行此操作,因此我首先创建了一个抽象类,在该类中放置了对所有报表有用的元素,并打算为从该类继承的每个报表创建一个类 然后,我从报表中调用一个静态方法,该方法创建报表类的实例并启动流程 REPORT ztesten. PARAMETERS p1 TYPE c. PARAMETERS p2 TYPE c. START-OF-SELECTION. zcl_clas

报告需要根据选择屏幕输入选择主数据,将所需字段映射到新的导出结构,转换为XML并保存到本地文件

由于有多个报表针对不同类型的主数据执行此操作,因此我首先创建了一个抽象类,在该类中放置了对所有报表有用的元素,并打算为从该类继承的每个报表创建一个类

然后,我从报表中调用一个静态方法,该方法创建报表类的实例并启动流程

REPORT ztesten.

PARAMETERS p1 TYPE c.
PARAMETERS p2 TYPE c.

START-OF-SELECTION.

  zcl_class=>main(
    EXPORTING p1 = p1
              p2 = p2 ). 
METHOD main.
  DATA(lo_class) =
    NEW zcl_tradenet_export_kostl(
        p1 = p1
        p2 = p2 ).
  lo_class->start_process( ).
ENDMETHOD.
由于一般建议避免使用全局数据,因此到目前为止,我一直在为使用什么作为属性而苦苦挣扎。目前,我存储在程序开始时从数据库中选择的所有参数和其他只读数据(这样做是为了避免在循环中多次选择),然后在整个报告以及导出结构中存储所需的数据。如果我想避免这种情况,我将不得不沿着调用堆栈拖动它们,这对我来说似乎更不切实际,即使它使用本地数据而不是全局数据

对于参数和DB数据,这似乎在某种程度上是正常的,因为属性只是读取而没有更改,但是对于导出结构,我有更多的担心,因为它是逐步填充的。然而,拖拽它似乎也不切实际,因为它会使方法签名膨胀

您将如何处理这些方面


最后一个问题:使用我目前的方法,如果选择屏幕中有许多元素或事先读取了许多数据库表,那么属性的数量可能会相当快地变大。您是否可以将它们分组到结构中以减少数量并使事情更清楚?

创建一个类,该类提供公共成员来存储所有参数

CLASS ztesten_config DEFINITION PUBLIC CREATE PUBLIC.
  PUBLIC SECTION.
    DATA p1 TYPE c.
    DATA p2 TYPE c.
ENDCLASS.

CLASS ztesten_config IMPLEMENTATION.
ENDCLASS.
实例化该类并将参数存储在其中

REPORT ztesten.

PARAMETERS p1 TYPE c.
PARAMETERS p2 TYPE c.

START-OF-SELECTION.
  DATA(config) = NEW ztesten_config( ).
  config->p1 = p1.
  config->p2 = p2.
  zcl_class=>main( config ). 
现在可以通过调用堆栈传递该对象。这可能仍然很烦人,但因为它只是一个参数,所以就不那么烦人了。它也是最干净的解决方案,因为它最小化了类的状态和耦合

METHOD main.
  DATA(lo_class) = NEW zcl_tradenet_export_kostl( ).
  lo_class->start_process( config ).
ENDMETHOD.
如果对象表示进程(“bla_计算”),而不是处理器(“bla_计算器”),则可以通过将配置传递给类的构造函数并让它们保存在某些私有属性中来减少参数传递的次数。这需要重新为每次执行报告实例化类

METHOD main.
  DATA(lo_class) = NEW zcl_tradenet_calculation( config ).
  lo_class->start_process( ).
ENDMETHOD.
通过应用类似singleton的模式,可以避免将对象完全传递到调用堆栈

CLASS ztesten_config DEFINITION PUBLIC CREATE PUBLIC.
  PUBLIC SECTION.
    DATA p1 TYPE c.
    DATA p2 TYPE c.
    CLASS-METHODS get_instance
      RETURNING
        VALUE(result) TYPE REF TO ztesten_config.
  PRIVATE SECTION.
    CLASS-DATA singleton TYPE REF TO ztesten_config.
ENDCLASS.

CLASS ztesten_config IMPLEMENTATION.
  METHOD get_instance.
    IF singleton IS NOT BOUND.
      singleton = NEW #( ).
    ENDIF.
    result = singleton.
  ENDMETHOD.
ENDCLASS.

METHOD somewhere_inside_tradenet_export_kostl.
  DATA(config) = ztesten_config=>get_instance( ).
  config->p1 [...]
ENDMETHOD.
所有这些模式都允许您提供测试数据而不是真正的报告输入,并在报告上下文之外利用您的类

对于报告的结果,您可以遵循类似的设计,通过生成一个对象来逐个接收和存储结果数据

构造参数总是一个好主意:它不仅使方法签名更小,而且还添加了哪些参数属于一起的上下文,以及如何


你熟悉吗?本节特别建议“通过将参数与结构和对象组合成有意义的集合,可以减少参数的数量。”

你好,Florian,感谢你的见解,尤其是对Singleton的见解,我没有想到在这种情况下使用它。如果有很多结构化成员(我的最后一个问题),你也可以对其进行评论吗?当然可以。将我的想法添加到帖子的末尾。