LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Hallo Kollegen,

ich wollte mal fragen, was ihr in welchen Fällen nutzt, um eine Zeile einer Tabelle zu betrachten und warum?
Bei neuen Programm/Reports nutze ich so gut wie immer REFERENCE INTO, einfach weil das meiner Meinung nach am Nächsten an OOP dran ist.

Ich sehe aber auch oft, dass innerhalb von Klassen Field-Symbols dafür verwendet werden. Ist ja natürlich generell nicht schlimm, aber ich würde gerne mal von eurem Erfahrungsschatz profitieren.

Grüße

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

a-dead-trousers hat geschrieben:Nur dass REFERENCE INTO auch im Kontext einer ganzen Klasse und darüber hinaus und nicht nur einer Methode funktioniert

Den Satz verstehe ich nicht.

Ralf

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Ich fürchte ohne den Expertenrat von gottfriedstroh kommen wir hier nicht weiter

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Aber wo ist denn jetzt der Vorteil? Bleiben wir mal beim Beispiel eines Parameters.
Du definierst einen Exportparameter vom Typ REF TO MATNR. Ok - das musst du nachher auch mit READ TABLE INTO REFERENCE füllen. Und bei Verwendung des Exportparameters im Aufrufer musst du dann dereferenzieren.
Die Alternative wäre ein Exportparameter vom Typ MATNR. Da müsste dann READ TABLE ASSIGNING und danach eine Zuweisung an den Parameter erfolgen. Dafür kann man sich nachher die Dereferenzierung sparen.

Die Anzahl der Stellen, wo der Exportparameter gefüllt wird ist klar definiert und (bei mir üblicherweise) sehr beschränkt. Die Anzahl der Aufrufer der Methode/Form hingegen ist meist nicht so klar definiert. Daher wäre mein Gedanke das Coding so zu gestalten dass der Aufrufer möglichst einfach an die Sache rangehen kann - und dazu gehört bei mir halt dass ich gerne direkt mit den Rückgabewerten arbeite anstatt sie noch dereferenzieren zu müssen.
( Und ich habe immer das Problem, dass ich an diversen Stellen prüfen muss, ob die Referenz überhaupt gebunden ist, wohingegen ich bei einem "echten" Rückgabeparameter immer von einer existierenden Variablen ausgehen kann )

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

ralf.wenzel hat geschrieben:Alles richtig, volle Zustimmung.

Wobei Referenzen aber deutlich flexibler sind, was man gelegentlich braucht. In unserer generischen Persistenzschicht wird immer ein REF TO DATA zurückgegeben. Weil die Klasse halt gar nicht weiß, was sie zurückgibt.

Genau in so einem Fall verwende ich auch gerne Referenzen. Aber in der Mehrzahl der Fälle ist ein READ TABLE oder LOOP AT ... bei mir eben hinreichend typisiert um darauf verzichten zu können. Und damit komme ich dann auch auf die Originalfrage dieses Threads zurück und kann nur sagen: Ich verwende LOOP ... INTO REFERENCE nur in Ausnahmefällen und nicht wie der OP im Regelfall.

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

nickname8 hat geschrieben:

black_adept hat geschrieben:Ich verwende LOOP ... INTO REFERENCE nur in Ausnahmefällen und nicht wie der OP im Regelfall.

Sondern? Field-Symbols?

Im allgemeinen Feldsymbole, es sei denn die Syntax zwingt mich Workareas zu verwenden. Und ich kann mich nicht entsinnen jemals ein loop into reference gemacht zu haben.

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

Ein kleines Anwendungsbeispiel für Datenreferenzen:
In OO sollte ja möglichst viel als "Objekt" abgebildet werden. Daher hab ich schon mehrere Frameworks gebastelt, wo es eine zentrale Datenklasse für einen effizienten (mehrfach)Datenzugriff und darum herum Funktionsklassen für die einzelenen Datensätze gibt. Dieses Funktionsklassen werden z.B. über den Primarykey eines Datensatzes identifiziert und bieten lediglich SET und GET Methoden für die einzelnen Datenfelder. Die eigentliche Datenhaltung bleibt aber in der zentralen Datenklasse und die Funktionsklassen arbeiten nur mit Referenzen auf die Tabellenzeilen in der Datenklasse. Nach außen sind dabei nur die GET und SET Methoden in den Funktionsklassen bzw. READ, SAVE, HAS_CHANGES, GET_DATASET usw. in der Datenklasse sichtbar. Die Datenhaltung ist somit "nahe" an der Datenbank und die Daten müssen so auch nicht "teuer" in die Funktionsklassen kopiert bzw. daraus gelesen werden.

Re: LOOP/READ TABLE ... INTO vs REFERENCE INTO vs ASSINGING

@adt: Ich glaube! verstanden zu haben was du machst. Aber könntest du jetzt mal ein simples Beispiel zu diesem Anwendungsfall beschreiben, wo du auf eine interne Tabelle mit LOOP at ... INTO REFERENCE arbeitest und wie du das dann nach oben oder unten durch die Methodeninterfaces durchreichst?