Tabelleneinträge als Objekte verwalten

Die Objektorientierung mit ABAP®: Vererbung, Dynamische Programmierung, GUI Controls (u.a. ALV im OO).
14 Beiträge • Seite 1 von 1
14 Beiträge Seite 1 von 1

Tabelleneinträge als Objekte verwalten

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Moin,

gegeben sei eine globale Klasse sowie eine Tabelle auf der Datenbank, die komplett gelesen wird und deren Einträge die Attribute der Objekte der genannten Klasse mit Leben füllen sollen. Angenommen, wir möchten Objekte der Tabelleneinträge von KNA1 oder BKPF erzeugen, das ist ein ganz gutes Beispiel. Dazu muss ich die Einträge lesen und die Objektzuordnung (welcher Tabelleneinträge gehört zu welchem Objekt) in der Klasse speichern (Multitone Design Pattern).

Nun frage ich mich, wie ich das am Besten mache. Eigentlich ist der Konstruktor eines Objektes dafür da, die Erzeugung EINES Objektes zu machen. Dazu müsste ich aber gezielt einen (beliebigen, aber noch nicht als Objekt dargestellten) Eintrag von der DB lesen.

Lese ich INTO TABLE, lese ich alle Einträge, kann daraus in einem LOOP alle Instanzen erzeugen, dann ist das aber kein Konstruktor im eigentlichen Sinne mehr, weil man eben nicht sagen kann "der Konstruktor dieses Objektes hat dieses Objekt ereugt", weil er schlichtweg alle erzeugt. Außerdem würde ich bei jeder Objekterzeugung die ganze Tabelle lesen, was sicher auf die Uhr geht.

Ich will aber auch nicht die Selektion im rufenden Programm machen und die Einträge häppchenweise dem Konstruktor aufdrücken, weil ich diese Logik gern als Bestandteil der Klasse haben möchte. Oder ist DAS der wesentliche Denkfehler?

Oder muss ich hier mit Persistenz arbeiten und persistente Klassen bilden?

Was genau habe ich nicht verstanden?
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Tabelleneinträge als Objekte verwalten

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
Ich verwende bei solchen Sachen immer zwei Klassen:
Eine Objektklasse die das Objekt zur Laufzeit verwaltet und eine Listenklasse die mehrere dieser Objekte verwaltet.
Wenn man nun nur ein Objekt braucht, ruft man den Konstruktor der Objektklasse auf und wenn man mehrere braucht dann den Konstruktor der Listenklasse.
Intern sind die beiden soweit verknüpft, dass beim Konstruktor des Objekts automatisch die Liste erzeugt wird, wenn sie noch nicht vorhanden ist, und die Objektinstanz wird dann automatisch eingetragen. So ist auch sichergestellt, dass nur eine Instanz zur Laufzeit existiert. Das Ganze verschachtle ich dann meist soweit, dass es eine Master-Klasse gibt die einen Zugriff auf alle in der Applikation verwendeten Listen bietet welche wiederum den Zugriff auf die Objektinstanzen bereitstellen.

Wie das Design-Paradigma dazu heißt weiß ich leider nicht aber ich wende es jetzt schon bei vielen meiner Projekte an und es hat sich bislang sehr gut bewährt.

lg ADT

EDIT: hmmm... Ich glaub das hab ich von SDO (Service Data Objects) übernommen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: Tabelleneinträge als Objekte verwalten

Beitrag von GastX (Specialist / 277 / 4 / 18 ) »
Hallo Ralf,
in dem von Dir genannten Beispiel finde ich es legitim, die Datenbeschaffung nicht in den einzelnen Objekten zu machen, da es ja um Massen geht.Was hältst Du von folgendem (grob, evtl. übersehe ich was):
Instanziierung protected und die Klasse bekommt
- eine Tabelle als statisches Attribut mit Zeilenaufbau "Keyfelder der Tabelle und Referenz auf Objekt dieser Klasse"
- eine statische READ_DB-Methode, die viele / alle Zeilen der DB-Tabelle behandelt
- Eine statische public GET_OBJECT-Methode, der man einen vollst. Key mitgeben kann und die eine Referenz auf das entsprechende Objekt zurückgibt
- Instanzattribute um die Daten einer einzelnen Zeile / eines einzelnen Objektes abzulegen
- ein Constructor(protected), der die vollständigen Objektdaten bekommt und in Instanzattributen sichert
- Instanzmethoden, um die Daten der Instanzen zurückzugeben.

READ_DB() liest alle (notwendigen) Zeilen in eine interne Tabelle, loopt dann drüber und erzeugt per Create Objekt jeweils ein Objekt. Dabei wird dem Instanzkonstruktor die Tabellenzeile mitgegeben, der sie dann in einem Instanzattribut sichert.

Der Zugriff könnte dann wie folgt laufen:

Man fragt per (statischem) GET_OBJECT() nach dem Objekt mit den interessierenden Daten. Diese Methode prüft, ob die statische Tabelle leer ist und, wenn ja, startet sie die READ_DB(), um danach in der gefüllten Tabelle per Key die Referenz auf das Objekt zu finden und zurück zu geben.
Wenn nein, schaut sie in der Tabelle mit dem Key.
Wenn sie nicht fündig wird (evtl. kam die Zeile nach Aufruf von READ_DB( ) auf die DB), könnte sie auch noch selber direkt auf der DB einen Single-Zugriff machen und bei Erfolg ein Objekt erzeugen und an die statische Tabelle dranhängen.
(Verzichtet man auf READ_DB bzw. ein initiales Einlesen aller Daten, so würde dieses Vorgehen alle Sätze bei Bedarf einzeln von der DB holen und selber puffern.)

Sofern vorhanden, bekommt der Aufrufer eine Objektreferenz zurück und kann aus dieser über eigene Getter-Methoden die Daten abfragen.

Passt das für Dein Szenario?
Gruss,
Frank

Re: Tabelleneinträge als Objekte verwalten

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
GastX hat geschrieben:Hallo Ralf,
in dem von Dir genannten Beispiel finde ich es legitim, die Datenbeschaffung nicht in den einzelnen Objekten zu machen, da es ja um Massen geht.
Da ist in meine Augen gar nicht das Problem, sondern die Unmöglichkeit. die Datenbeschaffung einzeln durchzuführen. Beispiel: Wir haben eine kundeneigene Tabelle mit z. B. zehn Einträgen. Nach OO-Kontext erzeugt man so viele Objekte wie es unterschiedliche Sätze in der Tabelle, indem man einen Datensatz liest, dazu das Objekt erzeugt und Tabellenkey und Objekt in einer Instanzentabelle sichert. Aber das "Ich lese einen (wirklich gezielt einen, denn nur den brauche ich für mein Objekt) Satz aus der Tabelle, den ich bisher noch nicht gelesen habe" wüsste ich nicht abzubilden.

Wäre das READ_DB nicht ein Fall für einen Klassenkonstruktor?

Komme ich mit Persistenzdiensten hier irgendwie weiter?
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Tabelleneinträge als Objekte verwalten

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Hallo Ralf,

mach doch eine Mischung aus A-D-Ts und Franks Vorschlägen.

Deine Klasse bekommt statische Methoden, welche die Massenerzeugung von noch fehlenden Objekten machen und welche sich falls nötig um die Verwaltung der Objekte kümmern, sowie deine schon vorhandenen Instanzmethoden welche sich um die individuellen Objekte kümmern.
Mir ist klar, dass A-D-Ts Vorschlag allgemeiner ist, da er mehrere Listklassen mit denselben Objekten drin verwalten kann. Aber es gibt auch Situationen, wo man eh nur genau eine Listklasse haben möchte und dann passt das obig vorgeschlagene Vorgehen ganz gut.
Die Vorschläge von Frank hören sich auch gut an - wobei ich allerdings public-Methoden/Konstruktoren vorziehen würde, die sich bei Direktaufruf trotzdem um das Eintragen von sich selber in den statischen Teil kümmern.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Tabelleneinträge als Objekte verwalten

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
Zur Lösung mit Static:
Das hab ich früher auch oft gemacht, bin davon aber abgekommen, weil es per Definition im Speicher verbleibt auch wenn die zugehörige Applikation (nicht Transaktion) abgeschlossen worden ist. Da bei es bei uns eine Haupttransaktion gibt die andere Programme/Applikationen aufruft, hat diese Lösung evtl. unnötigen Speicher verbraucht. Weiters hat man keine Trennung der Daten wenn zwei Anwendungen innerhalb ein- und derselben Transaktion laufen sich aber nicht gegenseitig beeinflussen sollen.

Man merkt ich denke in größeren Dimensionen :P

Aber für kleine Einzelanwendungen sind statische Attribute durchaus eine schnelle Alternative.

lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: Tabelleneinträge als Objekte verwalten

Beitrag von GastX (Specialist / 277 / 4 / 18 ) »
Jein.

Je nach Verwendung. Wenn Du die Daten durch zwei Applikationen modifizieren lässt und diese sich nicht beeinflussen sollen, dann stellt sich die Frage nach dem Zeitpunkt der Persistierung und ob die eine die Änderungen durch die andere irgendwann sehen soll. (Klar, Sperrobjekte spielen da noch eine Rolle.)
Mit dem Datenvolumen hast Du natürlich recht. Da kann man sich ggfs. noch was mit eigenen Beschränkungen überlegen (primitiv: wenn über x Sätze gelesen, dann lösche mal bis auf den letzten alle).
Wenn aber immer alle Sätze gelesen warden sollen, dann ist es eher hinderlich, wenn unterschiedliche Teile einer Transaktion das jeweils selber vorhalten.

(Habe gestern viel zu lange zum Abschicken gebraucht, hatte deswegen Deine Antwort auf Ralfs Frage gar nicht gesehen.)

Re: Tabelleneinträge als Objekte verwalten

Beitrag von GastX (Specialist / 277 / 4 / 18 ) »
@Ralf: mir kommen Persistenzdienste bei Daten aus genau einer Tabelle etwas oversized vor.
@black_adept / A-D-T: wie seht Ihr das?

Apropos einzelne Sätze: hast Du eine Klasse, die eine Liste der schon eingelesenen Daten vorhält (ist glaube ich sowohl in der Beschreibung von A-D-T als auch mir so möglich) kannst Du doch jeweils die GET_SINGLE-Methode erst dort nachschauen lassen und dann bei Bedarf aus der DB den einzelnen Satz nachlesen, Objekt erzeugen und in Verwaltungsliste eintragen.
Oder hatte ich den Punkt von Ralf missverstanden?

Re: Tabelleneinträge als Objekte verwalten

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
GastX hat geschrieben:Je nach Verwendung. Wenn Du die Daten durch zwei Applikationen modifizieren lässt und diese sich nicht beeinflussen sollen, dann stellt sich die Frage nach dem Zeitpunkt der Persistierung und ob die eine die Änderungen durch die andere irgendwann sehen soll. (Klar, Sperrobjekte spielen da noch eine Rolle.)
Ja, da hast du recht. Ist vielleicht ein blödes Beispiel gewesen geb ich zu. Ich sehe die Listen hier eher im Sinne einer allgemeinen Objekt Sammlung (vgl. Vector in Java). Wo die Daten herkommen ist dann zweitrangig und könnte sich dann im ungüstigsten Fall ohne klare Applikationstrennung überschneiden. Die Instanzierung mehrerer Objekte gleichzeitig ist dann eine Zusatzfunktion die in einer Ableitung dazu kommt.
Aber ich schweife wieder mal ab...

@Ralf: War schon was passendes bei den Vorschlägen für dich dabei?

Nochwas zu den persistenten Klassen: Die hab ich bislang noch nicht eingesetzt gerade weil sie NUR EINE TABELLE gleichzeitig verwalten können. Ich verwende aber gerne auch Texttabellen zu meine Datentabellen und würde diese dann auch in einem Rutsch bearbeiten wollen. Die ganzen internen Funktionen, die normalerweise automatisch generiert werden können, funktionieren damit aber nicht. Ich müsste also erst alles wieder selber schreiben.

lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: Tabelleneinträge als Objekte verwalten

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
black_adept hat geschrieben:Hallo Ralf,

mach doch eine Mischung aus A-D-Ts und Franks Vorschlägen.

Deine Klasse bekommt statische Methoden, welche die Massenerzeugung von noch fehlenden Objekten machen und welche sich falls nötig um die Verwaltung der Objekte kümmern, sowie deine schon vorhandenen Instanzmethoden welche sich um die individuellen Objekte kümmern..
Das habe ich vor, daher meine Frage: Wäre das Einlesen der Gesamt-Daten nicht ein Fall für einen Klassenkonstruktor? Allerdings: Wenn ich nach jeder DB-Operation die Daten frisch lesen will, brauche ich wohl doch eine konventionelle statische Methode....

Sry, war krank...
Zuletzt geändert von ralf.wenzel am 20.05.2014 07:25, insgesamt 1-mal geändert.
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Tabelleneinträge als Objekte verwalten

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
GastX hat geschrieben:@Ralf: mir kommen Persistenzdienste bei Daten aus genau einer Tabelle etwas oversized vor.
@black_adept / A-D-T: wie seht Ihr das?

Apropos einzelne Sätze: hast Du eine Klasse, die eine Liste der schon eingelesenen Daten vorhält (ist glaube ich sowohl in der Beschreibung von A-D-T als auch mir so möglich) kannst Du doch jeweils die GET_SINGLE-Methode erst dort nachschauen lassen und dann bei Bedarf aus der DB den einzelnen Satz nachlesen, Objekt erzeugen und in Verwaltungsliste eintragen.
Oder hatte ich den Punkt von Ralf missverstanden?
Zu den Persistenzdiensten: Das ist Neuland für mich, daher wäre es vielleicht gar nicht so schlecht, sowas Einfaches für die erste Umsetzung zu wählen ;)

Das Problem ist, dass ich nur mit dem Arbeiten kann, was ich schon habe. Schwer zu erklären: Ich selektiere die kundeneigenen Belege auf der Datenbank, die den Selektionskriterien entsprechen. Diese landen in einem ALV, mit dem der Anwender arbeitet. Ich komme gar nicht in die Situation, dass ich einen Beleg einzeln nachlesen muss, weil ich von der Existenz eines Beleges erst durch das Selektionsergebnis erfahre.
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Tabelleneinträge als Objekte verwalten

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
a-dead-trousers hat geschrieben:Nochwas zu den persistenten Klassen: Die hab ich bislang noch nicht eingesetzt gerade weil sie NUR EINE TABELLE gleichzeitig verwalten können. Ich verwende aber gerne auch Texttabellen zu meine Datentabellen und würde diese dann auch in einem Rutsch bearbeiten wollen. Die ganzen internen Funktionen, die normalerweise automatisch generiert werden können, funktionieren damit aber nicht. Ich müsste also erst alles wieder selber schreiben.

lg ADT
Welche internen Funktionen meinst du? Persistenzklassen eignen sich doch GERADE, um Tabellenbündel gescheit zu verwalten....
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Tabelleneinträge als Objekte verwalten

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
ralf.wenzel hat geschrieben:Welche internen Funktionen meinst du? Persistenzklassen eignen sich doch GERADE, um Tabellenbündel gescheit zu verwalten....
Tabellenbündel ja, aber je Klasse wird vom Standard nur ein Schlüssel unterstützt. Möchte man mehrere Tabellen deren Key nicht übereinstimmt (1:N) auf einmal bearbeiten braucht man mehrere Klassen. Was bei Texttabellen (SPRAS) ja der Fall ist.
ODER
Man programmiert die internen Methoden der generierten Agent-Klasse (CB_) selbst. ("Manuelle Implementierung der Datenbank-Zugriffsschicht")
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Re: Tabelleneinträge als Objekte verwalten

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
Okay... Ich scheine nicht der einzige mit dem Problem zu sein:
http://scn.sap.com/thread/3358250
Aber die Lösung ist (wieder einmal) denkbar einfach:
http://scn.sap.com/message/14082219#14082219
Das persistente Objekt der Text-Tabelle wird als Attribut zur Datentabelle hinzugefügt.

:oops:
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.18
Basis: 7.50

Seite 1 von 1

Vergleichbare Themen

1
Antw.
1054
Views
Objekte verwalten
von tevan100 » 25.10.2017 14:38 • Verfasst in ABAP Objects®
1
Antw.
1464
Views
Verwalten von Bankkrediten
von nocrap » 16.10.2008 17:49 • Verfasst in Financials
0
Antw.
1477
Views
11
Antw.
9392
Views
Layout Variante Verwalten
von Sava » 23.07.2013 11:40 • Verfasst in ABAP® für Anfänger
6
Antw.
2981
Views
Texte Verwalten im Mahnlauf
von Michi Müller » 16.12.2004 16:54 • Verfasst in Financials

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.