Persistente Klassen für was ?
Ey, jetzt komm mir nicht so...Alpha hat geschrieben:Hi Haubi
also ich sag auch zum Tutorial für Shared Objects nicht nein
Guckst Du...
Gruß,
Haubi
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Danke für die Blumen...Alpha hat geschrieben:Okay danke, ich dachte zwar, dass ich von deinem Wissen profitieren könnte, aber okay nehme ich halt das von SAP wird sicher nicht so gut sein
Mal sehen, vielleicht habe ich ja mal etwas Zeit, dann mache ich mal ein Tutorial. Reicht 2012?
Gruß und 'n schönes WE,
Haubi
Hallo,
Normalerweise holt man Datenzeilen von der DB in eine Tabelle, macht was damit und schreibt gänderte oder neue Zeilen in die DB.
SAP-konform sammelt man noch alle Einfügungen, Änderungen, Löschungen und "fährt" sie bei Commit Work wirklich auf die DB
Der Persistenzdienst mach nichts anderes, als alle Lese und Schreiboperationen auf Tabellen zu kapseln und alle Datenzeilen als Objekte im Speicher zu halten. Alle Änderungen werden geparkt und bei Commit-Work auf die DB fortgeschrieben.
"Dienst" ist vielleicht der falsche Begriff. Es wird nur aus Coding-Vorlagen das Coding für "individuelle" Objekte auf Grundlage einer DB-Tabelle erzeugt.
Ich arbeite mit tausenden von Objekten zu mehreren Typen im Speicher, kopiere, dupliziere, ändere und lösche. Alles kein Problem auch.
Wenn ich die Doku noch recht in Erinnerung habe, kann man die Persistenzobjekte im globalen Memory anlegen, so daß jeder User, jeder Modus, jede "Transaktion" auf DIESELBEN Objekte zugreift. Sind das die Shared-Objects???
Gruß
babap
P.S. diese Smilies sind wirklich der letze Sch****!
Haubi hat geschrieben:...
Ich hatte bereits vor einigen Jahren das Vergnügen mit den persistenten Objekten und habe auf der diesjährigen TechEd festgestellt, dass die Technik immer noch nicht eingestampft ist.
Bei meinen Tests hatte ich Probleme mit der Performance, der Flexibilität und dem Handling. Demnach habe ich das Thema zu den Akten gelegt und schreibe meine Persistenzschichten schön selbst. Da weiss ich, was ich habe. Guten Abend...
...
naja, vor ein paar Jahren mal ausprobiert, auf die Nase gefallen und selbst weitergewurschtelt, und dann noch jedem davon abgeraten sich jemals wieder damit zu beschäftigen.Haubi hat geschrieben:...
Ich bin ja gerne bereit, mich mit den Neuerungen der SAP zu beschäftigen. Dann aber eher mit sinnvollen Themen wie Shared Objects etc. Die Persistent Objects hingegen braucht IMHO kein Mensch. Wenn ich da falsch liege lasse ich mich natürlich gerne eines besseren belehren.
...
Normalerweise holt man Datenzeilen von der DB in eine Tabelle, macht was damit und schreibt gänderte oder neue Zeilen in die DB.
SAP-konform sammelt man noch alle Einfügungen, Änderungen, Löschungen und "fährt" sie bei Commit Work wirklich auf die DB
Der Persistenzdienst mach nichts anderes, als alle Lese und Schreiboperationen auf Tabellen zu kapseln und alle Datenzeilen als Objekte im Speicher zu halten. Alle Änderungen werden geparkt und bei Commit-Work auf die DB fortgeschrieben.
"Dienst" ist vielleicht der falsche Begriff. Es wird nur aus Coding-Vorlagen das Coding für "individuelle" Objekte auf Grundlage einer DB-Tabelle erzeugt.
Ich arbeite mit tausenden von Objekten zu mehreren Typen im Speicher, kopiere, dupliziere, ändere und lösche. Alles kein Problem auch.
Wenn ich die Doku noch recht in Erinnerung habe, kann man die Persistenzobjekte im globalen Memory anlegen, so daß jeder User, jeder Modus, jede "Transaktion" auf DIESELBEN Objekte zugreift. Sind das die Shared-Objects???
Gruß
babap
P.S. diese Smilies sind wirklich der letze Sch****!
Moooment. Da muss ich doch mal etwas klarstellen:babap hat geschrieben:Hallo,
Haubi hat geschrieben:...
Ich hatte bereits vor einigen Jahren das Vergnügen mit den persistenten Objekten und habe auf der diesjährigen TechEd festgestellt, dass die Technik immer noch nicht eingestampft ist.
Bei meinen Tests hatte ich Probleme mit der Performance, der Flexibilität und dem Handling. Demnach habe ich das Thema zu den Akten gelegt und schreibe meine Persistenzschichten schön selbst. Da weiss ich, was ich habe. Guten Abend...
...naja, vor ein paar Jahren mal ausprobiert, auf die Nase gefallen und selbst weitergewurschtelt, und dann noch jedem davon abgeraten sich jemals wieder damit zu beschäftigen.Haubi hat geschrieben:...
Ich bin ja gerne bereit, mich mit den Neuerungen der SAP zu beschäftigen. Dann aber eher mit sinnvollen Themen wie Shared Objects etc. Die Persistent Objects hingegen braucht IMHO kein Mensch. Wenn ich da falsch liege lasse ich mich natürlich gerne eines besseren belehren.
...
- Es steht jedem frei, das Zeug auszuprobieren und mich davon zu überzeugen, dass ich falsch liege.
- Ich habe die PO damals (und auch vor kurzem wieder) tatsächlich zum Laufen bekommen, allerdings haben mich weder Geschwindigkeit noch Handling überzeugt.
- Kann ja sein, dass ich wurschtel, aber mein Gewurschtel scheint so schlecht nicht zu sein
Ja, aber bei meinen Tests war jeder Zugriff ein SELECT SINGLE. Das mag bei einer Dialoganwendung noch i.O. sein, aber bei der Verarbeitung von Massendaten habe ich an der Stelle ein massives Problem.babap hat geschrieben: Normalerweise holt man Datenzeilen von der DB in eine Tabelle, macht was damit und schreibt gänderte oder neue Zeilen in die DB.
SAP-konform sammelt man noch alle Einfügungen, Änderungen, Löschungen und "fährt" sie bei Commit Work wirklich auf die DB
Der Persistenzdienst mach nichts anderes, als alle Lese und Schreiboperationen auf Tabellen zu kapseln und alle Datenzeilen als Objekte im Speicher zu halten. Alle Änderungen werden geparkt und bei Commit-Work auf die DB fortgeschrieben.
Auch was die Performance angeht?babap hat geschrieben:Ich arbeite mit tausenden von Objekten zu mehreren Typen im Speicher, kopiere, dupliziere, ändere und lösche. Alles kein Problem auch.
Shared objects sind Datenobjekte, die im Memory des Applikationsservers liegen. Mit Persistenz hat das primär nicht zu tun. Ich weiss auch nicht, ob man beide Konzepte miteinander kombinieren kann.babap hat geschrieben: Wenn ich die Doku noch recht in Erinnerung habe, kann man die Persistenzobjekte im globalen Memory anlegen, so daß jeder User, jeder Modus, jede "Transaktion" auf DIESELBEN Objekte zugreift. Sind das die Shared-Objects???
Der Vorteil der SO ist, dass ein User ein beliebig komplexes Objekt erzeugen kann, das dann von allen anderen Usern auf dem gleichen AppServer benutzt wird ohne dass dieses neu aufgebaut werden muss (in Form von teuren DB-Zugriffen). Hierbei gibt es z.B. eine Versionierung (wenn ein User auf das bestehende Objekt schreibend zugreift wird eine neue Version erzeugt, die als aktiv markiert wird sobald der ändernde Zugriff abgeschlossen ist), Verdrängungsmechanismen, Gültigkeiten etc.
Gruß,babap hat geschrieben: Gruß
babap
haubi
Zumindest gibbet's bessere...babap hat geschrieben: P.S. diese Smilies sind wirklich der letze Sch****!
Hallo,
ich habe z.B. einen Buchungspool für beliebige Uploads/CSV/TXT-Files geschrieben. Jede Buchungszeile ist erstmal ein SAP-Objekt und wird als SAP-Tabellenzeile abgespeichert (Rohdaten). Für die weitere Bearbeitung im Dialog müssen schon mal mehrere tausend Kopfdaten- oder Rohdatenzeilen wieder eingelesen werden. Das ist nicht der Performance-Engapß (Aufwändig ist die Interpretation der Daten und Umwandlung in anzeigefähige und buchbare Datensätze).
Das Einladen von DB kann man Mithilfe einer Query oder von frei formulierten Selektionsbedingungen machen. Dann werden alle Objekte zur Verfügung gestellt, die den Kriterien entsprechen. Ob dabei Select-Single oder Select into Table gemacht wird, weiß ich nicht.
Gruß
babap
ja,Haubi hat geschrieben:...
Ja, aber bei meinen Tests war jeder Zugriff ein SELECT SINGLE. Das mag bei einer Dialoganwendung noch i.O. sein, aber bei der Verarbeitung von Massendaten habe ich an der Stelle ein massives Problem.
Auch was die Performance angeht?babap hat geschrieben:Ich arbeite mit tausenden von Objekten zu mehreren Typen im Speicher, kopiere, dupliziere, ändere und lösche. Alles kein Problem auch.
ich habe z.B. einen Buchungspool für beliebige Uploads/CSV/TXT-Files geschrieben. Jede Buchungszeile ist erstmal ein SAP-Objekt und wird als SAP-Tabellenzeile abgespeichert (Rohdaten). Für die weitere Bearbeitung im Dialog müssen schon mal mehrere tausend Kopfdaten- oder Rohdatenzeilen wieder eingelesen werden. Das ist nicht der Performance-Engapß (Aufwändig ist die Interpretation der Daten und Umwandlung in anzeigefähige und buchbare Datensätze).
Das Einladen von DB kann man Mithilfe einer Query oder von frei formulierten Selektionsbedingungen machen. Dann werden alle Objekte zur Verfügung gestellt, die den Kriterien entsprechen. Ob dabei Select-Single oder Select into Table gemacht wird, weiß ich nicht.
Gruß
babap
Beitrag
von ralf.wenzel (Top Expert / 3927 / 200 /
281
)
»
Ich beschäftige mich gerade intensiver mit dem Thema und bin ganz schön erschrocken. Ich brauche zum Beispiel zum Starten einer Anwendung alle Sätze einer Tabelle, die bestimmten Selektionsbedingungen entsprechen. In konventionellem ABAP steht dann da:
und dann 14 weitere
Wenn ich stattdessen ein Query-Manager-Objekt erzeuge und die Abfrage darüber mache, codiere ich mir einen Wolf - so weit, dass ich mich echt frage, ob ich nix Besseres zu tun habe - zumal ich in einem meiner Bücher gelesen habe, dass man bei der Verwaltung von Massendaten (ab wann sind Daten Massendaten?) lieber eigene Suchdienste schreiben soll, weil das sonst performancekritisch wird.
Die Wahrheit ist eigentlich noch komplizierter, denn die Selektion ist ohnehin ziemlich langsam, weil die eigentlichen Nutzdaten in einem RAW-Feld gespeichert ist (die Tabelle wird für Datensätze unterschiedlichen Aufbaus verwendet, die 14 Felder "links" von dem RAW-Feld sind wirklich nur für die Selektion da!), so dass ich zusätzlich mit IMPORT (diverse Strukturen und Tabellen) FROM DATABASE ztab erst die Daten auflösen muss.
Mein Fazit: Nettes Spielzeug für Leute, die zuviel Zeit haben, die Vorteile kann ich derzeit nicht wirklich erkennen (die müssten anhand des enormen Aufwandes ja signifikant sein). Ich denke, ich werde dann doch lieber "banale", wenngleich gekapselte, OpenSQL-Anweisungen verwenden, um die Tabelle zu lesen und zu ändern.
Code: Alles auswählen.
SELECT *
FROM ztab INTO TABLE itab
WHERE feld1 IN s_feld1...Code: Alles auswählen.
AND feldx in s_feldxDie Wahrheit ist eigentlich noch komplizierter, denn die Selektion ist ohnehin ziemlich langsam, weil die eigentlichen Nutzdaten in einem RAW-Feld gespeichert ist (die Tabelle wird für Datensätze unterschiedlichen Aufbaus verwendet, die 14 Felder "links" von dem RAW-Feld sind wirklich nur für die Selektion da!), so dass ich zusätzlich mit IMPORT (diverse Strukturen und Tabellen) FROM DATABASE ztab erst die Daten auflösen muss.
Mein Fazit: Nettes Spielzeug für Leute, die zuviel Zeit haben, die Vorteile kann ich derzeit nicht wirklich erkennen (die müssten anhand des enormen Aufwandes ja signifikant sein). Ich denke, ich werde dann doch lieber "banale", wenngleich gekapselte, OpenSQL-Anweisungen verwenden, um die Tabelle zu lesen und zu ändern.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo,
Zum Thema Raw-Daten mit verschiedenen Strukturen in einer Tabelle mit ein paar Schlüsselfeldern vorne dran, habe ich bei meinem letzten Kunden sehr schlechte Erfahrungen bezüglich Perfomance gemacht. Gerade im Zusammenhang mit der Umwandlung (Hin- und Zurück) in das Raw-Format und von der Bearbeitungszeit der Daten in der Datenbank gab es erschreckende Effekte. (Die DB mochte das garnicht so gerne, dass ein Riesenfeld unstrukturierter Sch**tt da abgeladen wurde ... beim Schreiben und erst recht beim Lesen brauchte sie um Faktoren länger, als bei einem strukturierten Datenfeld ... die muss nämlich, statt bekannte Felder wegzuschreiben, erstmal einen Platz für das riesige BLOB suchen ... und wenn das dann noch aufgeteilt werden muss ... nee, dat isset nich ...)
Zum Thema Objektdienste habe ich mittlerweile umfangreiche Erfanrungen gesammelt.
Auch bei Massendaten (10.000, 20.000 Sätze) hatte ich weder Speicher noch Performanceprobleme.
Der Select über Business-Key ist genauso einfach, wie der "Hausfrauen-Select".
Gerade als Puffer sind diese Objekte einsame Spitzenklasse, auch für Customizing-Tabellen etc.
Es gibt so viele Möglichkeiten, die Objekte "von selbst" das machen zu lassen, was man sonst an anderer Stelle immer mal wieder kodieren müsste.
Auch im Zusammenhang mit dem Wegschreiben und mit Commit-Work bietet das Ganze eine wesentliche Entlastung des Codings.
Der Persistzenzienst liest jedes benötigte Objekt (auch mehrere zu einer Selektion) und puffert diese. Er behält sowieso alles, was er mal gelesen hat im Puffer ... und sorgt dafür, dass die geänderten Daten weggeschrieben werden.
Sollte es notwendig sein, eine Untermenge von Datensätzen gemeinsam zu behalten oder zu bearbeiten, setzt man einfach einen weiteren Objektdienst, oder eine Klasse dazwischen, die die "Fäden" zu dem eben gelesenen Bündel "Ballons" in der Hand hält ... und diese ggf. alle gemeinsam bearbeitet, abnudelt, zählt, korrigiert oder sonstwas damit macht.
Für mich gilt in einem neuen Konzept ... nie wieder ein normaler SELECT-Befehl, gerade wenn es ums Puffern und Wegschreiben bei Commit geht.
Meine Empfehlung: erst ausprobieren, oder jemand fragen, der sich damit auskennt bevor man es in "Bausch und Bogen" abqualifiziert :-/
Viele Grüße
babap
Zum Thema Raw-Daten mit verschiedenen Strukturen in einer Tabelle mit ein paar Schlüsselfeldern vorne dran, habe ich bei meinem letzten Kunden sehr schlechte Erfahrungen bezüglich Perfomance gemacht. Gerade im Zusammenhang mit der Umwandlung (Hin- und Zurück) in das Raw-Format und von der Bearbeitungszeit der Daten in der Datenbank gab es erschreckende Effekte. (Die DB mochte das garnicht so gerne, dass ein Riesenfeld unstrukturierter Sch**tt da abgeladen wurde ... beim Schreiben und erst recht beim Lesen brauchte sie um Faktoren länger, als bei einem strukturierten Datenfeld ... die muss nämlich, statt bekannte Felder wegzuschreiben, erstmal einen Platz für das riesige BLOB suchen ... und wenn das dann noch aufgeteilt werden muss ... nee, dat isset nich ...)
Zum Thema Objektdienste habe ich mittlerweile umfangreiche Erfanrungen gesammelt.
Auch bei Massendaten (10.000, 20.000 Sätze) hatte ich weder Speicher noch Performanceprobleme.
Der Select über Business-Key ist genauso einfach, wie der "Hausfrauen-Select".
Gerade als Puffer sind diese Objekte einsame Spitzenklasse, auch für Customizing-Tabellen etc.
Es gibt so viele Möglichkeiten, die Objekte "von selbst" das machen zu lassen, was man sonst an anderer Stelle immer mal wieder kodieren müsste.
Auch im Zusammenhang mit dem Wegschreiben und mit Commit-Work bietet das Ganze eine wesentliche Entlastung des Codings.
Der Persistzenzienst liest jedes benötigte Objekt (auch mehrere zu einer Selektion) und puffert diese. Er behält sowieso alles, was er mal gelesen hat im Puffer ... und sorgt dafür, dass die geänderten Daten weggeschrieben werden.
Sollte es notwendig sein, eine Untermenge von Datensätzen gemeinsam zu behalten oder zu bearbeiten, setzt man einfach einen weiteren Objektdienst, oder eine Klasse dazwischen, die die "Fäden" zu dem eben gelesenen Bündel "Ballons" in der Hand hält ... und diese ggf. alle gemeinsam bearbeitet, abnudelt, zählt, korrigiert oder sonstwas damit macht.
Für mich gilt in einem neuen Konzept ... nie wieder ein normaler SELECT-Befehl, gerade wenn es ums Puffern und Wegschreiben bei Commit geht.
Meine Empfehlung: erst ausprobieren, oder jemand fragen, der sich damit auskennt bevor man es in "Bausch und Bogen" abqualifiziert :-/
Viele Grüße
babap
Beitrag
von ralf.wenzel (Top Expert / 3927 / 200 /
281
)
»
Dann fangen wir doch mal ganz einfach an. Zeig mir doch mal bitte das Äquivalent zu:
Die Selektionsoptionen hab ich mir jetzt geschenkt, weil ich unterwegs bin und auf dem iPhone tippe. Mehr brauche ich aber für eine solche Selektion dann nicht.
Und dann wüsste ich gern, welche Vorteile mir das konkret (!) bietet.
Ich lerne gern dazu!
Code: Alles auswählen.
Data: mara type sorted table of mara
with unique key matnr.
select * from mara into table mara
where matnr in s_matnr
and mtart in s_mtart.
Und dann wüsste ich gern, welche Vorteile mir das konkret (!) bietet.
Ich lerne gern dazu!
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo,
wenn Du eine "sorted" Table für bestimmte Zwecke brauchst, dann sind die persistenten Objekte nicht das richtige.
(Über die "Fragwürdigkeit" von IN-Statements ... auch in Bezug auf Performance und Beschränkungen der Anzahl etc. möchte ich hier nicht eingehen ...
Dass je nach Datenbank das SAP-System oder die Datenbank dann sowieso SELECT SINGLE machen, ist weitgehend unbekannt ...)
Wie man sowas alternativ mach, kann ich hier, ohne SAP-System, ohne Beispieldatenbank etc. nicht zeigen.
Leider ist die Dokumentation und Hilfe von SAP dazu nicht ausreichend.
Habe das in einem der letzten Projekte auch Leuten bei SAP selbst beigebracht, wie sowas funktioniert (hatten die noch nie gesehen...)
War ebenfalls die Fragestellung, im Programmablauf was lesen, ändern, das Geänderte zur Verfügung haben, noch noch bevor man COMMIT machen DARF, musste ich schnellstmöglichst realisieren, nachdem es Leute aus I***** nach langer Zeit kurz vor knapp nicht geschafft hatten, das mit konventionellen Mitteln hinzukriegen ...
(wenn man sucht, findet man immer mehr SAP-Coding, welches genau die persistenden Dienste verwendet ... man gewöhnt sich dran!)
Einen wichtigen Vorteil habe ich noch nicht erwähnt:
Die persistenten Objekte, d.h. den kompletten Datenzugriff und das Wegschreiben, sowie einige private und zusätzliche Funktionen, die man dort reingepackt hat, kann man ohne Schwierigkeiten im Dialog testen.
D.H. alle Leseoperationen, Manipulationsoperationen und das Wegschreiben hat man bei Fertigstellung dieses Teils der Anwendung komplett erledigt und getestet ... Es ist dann gekapselt und kann "weiter" oben ohne Bedenken verwendet werden ...
Da Du ein "alter" Praktiker bist, gehe ich davon aus, dass es das Beste ist, ich zeige Dir das am lebenden Objekt.
Wenn Du möchtest und Dein Budget einen Tag dafür "Zeit" hat, gerne
Viele Grüße
babap
wenn Du eine "sorted" Table für bestimmte Zwecke brauchst, dann sind die persistenten Objekte nicht das richtige.
(Über die "Fragwürdigkeit" von IN-Statements ... auch in Bezug auf Performance und Beschränkungen der Anzahl etc. möchte ich hier nicht eingehen ...
Dass je nach Datenbank das SAP-System oder die Datenbank dann sowieso SELECT SINGLE machen, ist weitgehend unbekannt ...)
Wie man sowas alternativ mach, kann ich hier, ohne SAP-System, ohne Beispieldatenbank etc. nicht zeigen.
Leider ist die Dokumentation und Hilfe von SAP dazu nicht ausreichend.
Habe das in einem der letzten Projekte auch Leuten bei SAP selbst beigebracht, wie sowas funktioniert (hatten die noch nie gesehen...)
War ebenfalls die Fragestellung, im Programmablauf was lesen, ändern, das Geänderte zur Verfügung haben, noch noch bevor man COMMIT machen DARF, musste ich schnellstmöglichst realisieren, nachdem es Leute aus I***** nach langer Zeit kurz vor knapp nicht geschafft hatten, das mit konventionellen Mitteln hinzukriegen ...
(wenn man sucht, findet man immer mehr SAP-Coding, welches genau die persistenden Dienste verwendet ... man gewöhnt sich dran!)
Einen wichtigen Vorteil habe ich noch nicht erwähnt:
Die persistenten Objekte, d.h. den kompletten Datenzugriff und das Wegschreiben, sowie einige private und zusätzliche Funktionen, die man dort reingepackt hat, kann man ohne Schwierigkeiten im Dialog testen.
D.H. alle Leseoperationen, Manipulationsoperationen und das Wegschreiben hat man bei Fertigstellung dieses Teils der Anwendung komplett erledigt und getestet ... Es ist dann gekapselt und kann "weiter" oben ohne Bedenken verwendet werden ...
Da Du ein "alter" Praktiker bist, gehe ich davon aus, dass es das Beste ist, ich zeige Dir das am lebenden Objekt.
Wenn Du möchtest und Dein Budget einen Tag dafür "Zeit" hat, gerne
Viele Grüße
babap
Beitrag
von ralf.wenzel (Top Expert / 3927 / 200 /
281
)
»
Wo wäre das dann (rein geographisch)?
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3927 / 200 /
281
)
»
Örks - ich wohne in HAMBURG. Allein nach Frankfurt fahre ich vier Stunden - pro Weg!babap hat geschrieben:Wohne in Rhein Main ...
... von da ist man "ruck-zuck" in den größeren Orten der Republik
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hi,
hier würde ich mich sehr gerne mal dranhängen. Ich möchte mich schon länger mal mit den Object Services beschäftigen. Ich denke das wäre mal ein guter Einstieg.
Ich komme auch aus dem Rhein-Main Gebiet. Von daher denke ich sollte das jetzt kein größeres Problem darstellen. Zugriff auf Systeme etc. hätte ich natürlich auch.
Viele Grüße,
hier würde ich mich sehr gerne mal dranhängen. Ich möchte mich schon länger mal mit den Object Services beschäftigen. Ich denke das wäre mal ein guter Einstieg.
Ich komme auch aus dem Rhein-Main Gebiet. Von daher denke ich sollte das jetzt kein größeres Problem darstellen. Zugriff auf Systeme etc. hätte ich natürlich auch.
Viele Grüße,
...entwickelnder Berater...beratender Entwickler
Beitrag
von Apparatschik (ForumUser / 1 / 0 /
2
)
»
Hallo,
ich bin jetzt seit einem Jahr auch in der ABAP Welt unterwegs, ging ganz gut, da ich früher viel Cobol gemacht habe (verwandte Syntax) und mich auf der anderen Seite seit über 20 Jahren mit objektorientierten Design beschäftige. Da bin ich relativ schnell auch auf die Persistenten Klassen gestoßen und in unserem Projekt (Web-Services) durchgesetzt, dass wir die Dinger einsetzen. Nehmen einem viel Arbeit ab, auch wenn sie an der einen oder anderen Stelle noch etwas "hakelig" sind (nichts, mit dem man nicht leben könnte). Performance-Probleme konnte ich jedenfalls nicht feststellen (Gegenargument N. 1). Selbst die Response auf den Service-Request "Liste Abholen" mit über 1000 Objekten war sofort da. Aus dem Bauch heraus wage ich zu behaupten, dass sie grds. auch batch-tauglich sind.
Allerdings habe ich mir noch das eine oder andere dazugebaut, um mir das Leben etwas leichter zu machen. So z. B. Klassen zur Verwaltung von Suchbedingungen unter Nutzung des Composite Patterns, die mir für den Aufruf getPersistentByQuery den kompletten Input liefert, sodass ich wieder bei einem einzigen Call bin (Single-Call Prinzip). So bleibt der Business-Code clean. Außerdem noch zwei generische Methoden getStructure und setByStructure, die die Attribute auf Basis der Tabellenstruktur unter Nutzung der Runtime-Services rein bzw. rausschreiben...manchmal braucht man halt doch noch die Strukturen. Vor allem beim Set ist das praktisch, da man so das Casting über zusätzliche Hilfsvariablen von der Backe hat, wenn die Datenquelle zur Persistenten Klasse inkompatible Datentypen aufweist. Einfach zuerst in die Struktur mappen und abschließend setByStructure aufrufen.
M. E. bilden die Persistenten Klassen ganz gut das Repository Konzept, welches Eric Evans in seinem Buch "Domain Driven Design" erläutert, ab. Weswegen daher im Netz soviele Vorbehalte (oder Vorurteile?) geäußert werden, ist aus meiner Erfahrung heraus nicht nachvollziehbar. Sachliche Gründe sehe ich da eher weniger. Ich vermute, es liegt daran, dass sehr viele "erfahrene" ABAP Entwickler noch ziemlich old school unterwegs sind und nicht wirklich in der Objektorientierung angekommen sind. Zumindest hatte ich diesen Eindruck bei den Beratern, die bei uns im Hause unterwegs waren. Erst kannten sie die persistenten Klassen gar nicht, und als ich dann das Thema vorangetrieben habe, hatten sie nichts besseres zu tun, als Gegenargumente zu sammeln. Nur sich nicht auf was neues einlassen und stur den alten Stiefel pflegen...
Fakt ist: Durch ein stringentes OO-Design unter Nutzung der Persistenten Klassen sparen wir ggü. dem Vorgängersystem (batchorientierter Datenaustausch) ca. 80% Code ein (da gab's noch viele andere Schwachpunkte...). Alleine die 50 quasi code-gleichen Verbucherbausteine für die 50 Tabellen, die in dem Altsystem genutzt wurden...wer tut sich sowas freiwillig an? Auf meine Frage, was der Blödsinn denn soll, bekam ich als Antwort von einem der erfahrenen Berater: "Das macht man halt so in ABAP!" Und dachte sich wohl noch: "Dieser Halbwissende mit seinen nervigen Einwänden..." Ich sage: Nein das muss man nicht so machen. Einfach persistente Klassen nutzen und die ganze Datenbankzugriffsschicht wird generiert!
Gruß
Apparatschik
ich bin jetzt seit einem Jahr auch in der ABAP Welt unterwegs, ging ganz gut, da ich früher viel Cobol gemacht habe (verwandte Syntax) und mich auf der anderen Seite seit über 20 Jahren mit objektorientierten Design beschäftige. Da bin ich relativ schnell auch auf die Persistenten Klassen gestoßen und in unserem Projekt (Web-Services) durchgesetzt, dass wir die Dinger einsetzen. Nehmen einem viel Arbeit ab, auch wenn sie an der einen oder anderen Stelle noch etwas "hakelig" sind (nichts, mit dem man nicht leben könnte). Performance-Probleme konnte ich jedenfalls nicht feststellen (Gegenargument N. 1). Selbst die Response auf den Service-Request "Liste Abholen" mit über 1000 Objekten war sofort da. Aus dem Bauch heraus wage ich zu behaupten, dass sie grds. auch batch-tauglich sind.
Allerdings habe ich mir noch das eine oder andere dazugebaut, um mir das Leben etwas leichter zu machen. So z. B. Klassen zur Verwaltung von Suchbedingungen unter Nutzung des Composite Patterns, die mir für den Aufruf getPersistentByQuery den kompletten Input liefert, sodass ich wieder bei einem einzigen Call bin (Single-Call Prinzip). So bleibt der Business-Code clean. Außerdem noch zwei generische Methoden getStructure und setByStructure, die die Attribute auf Basis der Tabellenstruktur unter Nutzung der Runtime-Services rein bzw. rausschreiben...manchmal braucht man halt doch noch die Strukturen. Vor allem beim Set ist das praktisch, da man so das Casting über zusätzliche Hilfsvariablen von der Backe hat, wenn die Datenquelle zur Persistenten Klasse inkompatible Datentypen aufweist. Einfach zuerst in die Struktur mappen und abschließend setByStructure aufrufen.
M. E. bilden die Persistenten Klassen ganz gut das Repository Konzept, welches Eric Evans in seinem Buch "Domain Driven Design" erläutert, ab. Weswegen daher im Netz soviele Vorbehalte (oder Vorurteile?) geäußert werden, ist aus meiner Erfahrung heraus nicht nachvollziehbar. Sachliche Gründe sehe ich da eher weniger. Ich vermute, es liegt daran, dass sehr viele "erfahrene" ABAP Entwickler noch ziemlich old school unterwegs sind und nicht wirklich in der Objektorientierung angekommen sind. Zumindest hatte ich diesen Eindruck bei den Beratern, die bei uns im Hause unterwegs waren. Erst kannten sie die persistenten Klassen gar nicht, und als ich dann das Thema vorangetrieben habe, hatten sie nichts besseres zu tun, als Gegenargumente zu sammeln. Nur sich nicht auf was neues einlassen und stur den alten Stiefel pflegen...
Fakt ist: Durch ein stringentes OO-Design unter Nutzung der Persistenten Klassen sparen wir ggü. dem Vorgängersystem (batchorientierter Datenaustausch) ca. 80% Code ein (da gab's noch viele andere Schwachpunkte...). Alleine die 50 quasi code-gleichen Verbucherbausteine für die 50 Tabellen, die in dem Altsystem genutzt wurden...wer tut sich sowas freiwillig an? Auf meine Frage, was der Blödsinn denn soll, bekam ich als Antwort von einem der erfahrenen Berater: "Das macht man halt so in ABAP!" Und dachte sich wohl noch: "Dieser Halbwissende mit seinen nervigen Einwänden..." Ich sage: Nein das muss man nicht so machen. Einfach persistente Klassen nutzen und die ganze Datenbankzugriffsschicht wird generiert!
Gruß
Apparatschik
Folgende Benutzer bedankten sich beim Autor Apparatschik für den Beitrag (Insgesamt 2):
ewx • babap
Vergleichbare Themen
2
Antw.
Antw.
2766
Views
Views
Persistente Klasse für Massendatenverarbeitung
von eschi78 » 18.02.2015 16:56 • Verfasst in ABAP Objects®
von eschi78 » 18.02.2015 16:56 • Verfasst in ABAP Objects®
8
Antw.
Antw.
9109
Views
Views
Architektur von Abap-Klassen (Klassen Attribute)
von snooze » 12.04.2005 12:56 • Verfasst in ABAP Objects®
von snooze » 12.04.2005 12:56 • Verfasst in ABAP Objects®
20
Antw.
Antw.
2758
Views
Views
Globale Klassen oder Lokale Klassen
von ZF_SAPler » 29.11.2022 13:47 • Verfasst in ABAP® für Anfänger
von ZF_SAPler » 29.11.2022 13:47 • Verfasst in ABAP® für Anfänger
5
Antw.
Antw.
1023
Views
Views
TRX ME22n: Persistente Error-Message anzeigen lassen
von Elekam » 17.03.2021 09:37 • Verfasst in ABAP® für Anfänger
von Elekam » 17.03.2021 09:37 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 21 Stunden von ralf.wenzel 104 / 10274
vor 21 Stunden von ralf.wenzel 104 / 10274
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 21 Stunden von ralf.wenzel 104 / 10274
vor 21 Stunden von ralf.wenzel 104 / 10274