ABAP Clean Code

Re: ABAP Clean Code

Also, ich beantworte erstmal deine Frage konkret und dann schreibe ich was zum Umfeld: Wir hatten solche Fälle bisher nicht. Die Frage ist auch: Lässt man das lieber den (einen) DB-Server machen oder einen (der mehreren) SAP-Server. Wie man das lösen KANN, schreibe ich unten.

Was wir hatten, war FOR ALL ENTRIES, wo man schnell den Fehler macht, eine leere Tabelle zu übergeben. Den fangen wir ab und sagen dem Anwender "das ist falsch" ehe wir die DB ansprechen.

Zum Umfeld:

Was wir hier haben, ist eine Klassenhierarchie für die Persistenz. Ganz oben in der Basisklasse der ganzen Hierarchie gibt es eine Methode, die den SELECT (und wirklich nur den) enthält. Diese Methode könnte man redefinieren, um z. B. ein ORDER BY unterzubringen für bestimmte Fälle. Das haben wir z. B. gemacht für Cluster-Tabellen. Neben dem Hauptzweig für transparente Tabellen gibt es einen weiteren, wo diese Methode redefiniert ist und ein IMPORT bzw. EXPORT macht, von der erben alle Persistenzklassen für Clustertabellen. Für den Entwickler, der z. B. Daten selektiert, ist das völlig egal. Der sagt, was er hat und was er haben will und fertig. Im Zweifel weiß der nichtmal, dass das in einer Clustertabelle steht.

"Unter der Haube" ist eine Persistenzschicht sehr komplex, aber das muss den Aufrufer ja (wie gesagt) nicht interessieren. Der macht ein result = bla->read( selkrit ). selkrit kann eine Struktur der Tabelle sein, also z. B. MARA. Oder eine Tabelle dieser Struktur. Oder eine Struktur, bei der alle Einzelfelder RANGE-Tabellen sind für das jeweilige Feld. Oder eine Tabelle einer solchen RANGE-Tabellen-enthaltenden Struktur. Was man reinwirft, wird "drinnen" analysiert und das Ergebnis (hier: result) ist eine Tabelle der Einträge (also z. B. eine Tabelle vom Zeilentyp MARA).

Das sind jetzt nur ein paar Beispiele, letztlich liegt ein Customizing dahinter, welcher Typ als selkrit erwartet wird und welcher Typ in result geliefert wird. So eine Persistenzklasse hat man ratzfatz erstellt, weil fast alles aus der Basisklasse geerbt wird und man nur noch Zugriffsmethoden bauen muss (damit man cls=>read_mara4matnr( matnr ) machen kann statt maraobj->read( marastruc ) in der dann nur das MATNR-Feld belegt ist). Eine Zugriffsmethode in die Persistenzklasse schreiben ist nicht aufwendiger als einen SELECT zu schreiben. Die kann man sich aber im Grunde schenken, wenn man keine Zeit hat. Es gibt ja eine öffentliche Schnittstelle (siehe unten).

Sowas wie die WHERE-Bedingung wird dann aus den Inhalten von selkrit generiert.

Der Vorteil gegenüber BOPF ist, dass die SAP das nicht unterstützen muss. Das geht also mit JEDER Tabelle. Und der Vorteil der generischen Persistenzschicht ist, dass man die Persistenz komplett von der Geschäftslogik entkoppelt. Das heißt insbesondere auch, dass Änderungen in der Persistenz nicht zwangsläufig dazu führen, dass ich alle DB-Zugriffe anpassen muss. Im Grunde könnte man sogar Dateien hochladen über diese Persistenzschicht.

Mein Tipp: Fang damit an, solche Persistenzklassen zu bauen, in der du für jeden select eine Methode baust. Also eine Klasse für die MARA mit einer Methode read_from_matnr( ) - importing matnr returning mara, für die Selektion eines einzelnen MARA-Satzes anhand seiner MATNR. Irgendwann wirst du merken, was sich immer und immer wiederholt und das verlagerst du in eine Oberklasse. Und irgendwann wirst du die WHERE-Bedingung generisch erzeugen wollen, um sie nicht immer in die Methode reinschreiben zu müssen (nach dem Motto: Was ich habe, übergebe ich doch der Methode - warum muss ich dann noch die WHERE-Bedingung jedesmal reinschreiben?). So bildet sich nach und nach eine Persistenzschicht heraus und du lernst Schritt für Schritt, was du brauchst und wie du das umsetzt.

Wie z. B. unsere Idee "wir müssen für jedes Einzelfeld auch eine RANGETAB übergeben können, sonst funktionieren zu viele Selektionen nicht". Dann schreibt man eine Routine, die eine solche RANGETAB als selkrit-Komponente erkennt und entsprechend auswertet.

Irgendwann baust du dir z. B. Tabellenpufferungen da ein und so weiter und so fort.

Als allerersten Schritt würde ich aber ein Interface (ZIF_PERSISTABLE) definieren, das von allen Persistenzklassen implementiert wird. Du brauchst in erster Linie die Methoden create( ), read( ), update( ) und delete( ). Bereite dich jetzt schon darauf vor, dass die zukünftig deine zentralen Zugriffsmethoden sein werden. Dann brauchst du nichts einzureißen, während du dazulernst.


Ralf

Re: ABAP Clean Code

Du irrst, du hast 3392 Beiträge (mit diesem 3393) zur Auswahl, von denen jeder einen Danke-Button hat *rofl*


Ralf

Re: ABAP Clean Code

Klar kann ich das. Ich kann auch mit dem Ferrari Brötchen holen und mich wundern, dass ich die kaum schneller habe als mit dem Rad.

Fakt ist, dass man sich dazu einer Kompatibilitätsschicht bedient, und dann beschwerst du dich NICHT über die künstlich eingebaute Schicht, die man eigentlich nicht braucht.


Ralf

Re: ABAP Clean Code

SELECT *? Nein, gerade nicht. Wie kommst du darauf?


Ralf

Re: ABAP Clean Code

Das Wort „Beispiel“ ist Dir geläufig? Ich schrieb: Wenn du einen MARA-Satz zur MATNR selektieren willst....

Im Übrigen muss im Returning-Parameter nicht jedes Feld gefüllt sein. Dennoch hat man mehrere Werte in einem Parameter (was Voraussetzung ist für returning).


Ralf

Re: ABAP Clean Code

Ich denke Ralf meinte, wenn man mit Returning mehrere Werte zurück erhalten will, muss man das in eine Struktur verpacken und dann ist es egal, ob in dieser Struktur nur ein Feld gefüllt ist oder n.

Re: ABAP Clean Code

black_adept hat geschrieben: ↑

22.05.2019 09:50

Und wenn es um Eigenentwicklungen geht: Ich kann mich nicht entsinnen, dass ich oder ein anderer Entwickler in den Umgebungen in denen ich Coding habe Clustertabellen für irgend etwas verwendet hat wo ich auf den Gedanken kommen könnte so etwas wie falsche SELECTs darauf auszuprobieren.

Darum geht es ja gar nicht, es geht darum, dass viele mit Cluster-Tabellen gar nicht umgehen können - bei unserem Konzept muss man nichtmal wissen, was eine Clustertabelle ist. Man muss eigentlich überhaupt nicht wissen, was eine Tabelle ist und wie man darauf zugreift oder ob die Daten auf verschiedene Tabellen verteilt sind.

Ich muss wissen: "Ich hätte gern die Labordaten zu folgenden Blutspendern: ... ". Wo die herkommen und wie die sich zusammensetzen, ist dabei völlig nebensächlich. Das ist insbesondere dann spannend, wenn dabei auf die DB eines fremden Systems zugegriffen wird, ohne dass der Entwickler, der die Daten bekommt, das überhaupt weiß.

black_adept hat geschrieben: ↑

22.05.2019 09:50

Und letztlich: Wenn ich auf die MARA zugreifen will schreibe ich normalerweise SELECT...FROM MARA. Du schreibst irgend eine Klassenbasierten Zugriff, der dann im Anschluss genau das Selbe macht. Die Wahrscheinlichkeit, dass SAP die MARA so ändert, dass ich jemals meine Selects anpassen müsste halte ich für mehr als unwahrscheinlich.
Und wie ein Aufruf eines klassenbasierten Zugriffs auf die MARA gegenüber einem direkten SELECT auf die MARA die Persistenz von der Geschäftslogik entkoppelt entzieht sich mir bei genauerem Nachdenken auch - zumindest wenn ich nur deine Erklärungen durchgehe.

Also, wir haben hier ein agiles Projekt, wo sich die Tabellen in der Tat relativ häufig ändern. Zudem kann man schön Automatismen einbauen, die dann gleich für alle gelten (zum Beispiel das Füllen von "created_by..../updated_by...."-Feldern oder das Verhindern von Zugriffen mit leerer FOR ALL ENTRIES, Aufbauen einer zweiten DB-Verbindung für bestimmte Tabellen, um an der LUW vorbei Daten wegzuschreiben, etc.).

DAO-Klassen, wo dann explizit SELECTs drinstanden, hatte ich auch schon in Projekten, das macht auch nicht weniger Arbeit, man zentralisiert aber nichts.

Ralf