Eigene Customizingtabelle als Klasse?

Die Objektorientierung mit ABAP®: Vererbung, Dynamische Programmierung, GUI Controls (u.a. ALV im OO).

Eigene Customizingtabelle als Klasse?

Postby Stephanie1364 » Thu Jun 07, 2012 4:09 pm

Hallo,

als "Gelegenheitsentwickler" im HR-Bereich bin ich bisher immer mit klassischen ABAP unterwegs gewesen. Um mich an ABAP OBJECTS zu gewöhnen, will ich Jetzt einmal eine ganz kleine Anforderung in ABAP Objects umstezen.

Doch da gehen die Schwierigkeiten schon los. Ich habe zum privaten Vergnügen auch schon einmal ein kleines Spiel in JAVA entwickelt. Wenn ich aber versuche, mich zu ABAP OBJECTS zu belesen, stoße ich auf Aussagen, mal solle nicht so kleinteilige Klassen bilden, wie z.B. in JAVA üblich. Und man solle bloß nicht auf das ausgereifte Werkzeug der internen Tabelle verzichten.

Konkret hätte ich zunächst eine recht große Customizingtabelle im Report unterzubringen. Wenn ich die Aussagen gegen Kleinteiligkeit richtig interpretiere, definiere ich also nicht die Tabellenzeile als Klasse, sondern gleich die ganze Tabelle? Und biete alles was auf der Tabelle im Report zu passieren hat, als Methoden an? Wenn ja, baue ich das Ganze dann mit Hilfe der Persitenz-Unterstützung auf und muss mich um die Abbildung in der DB gar nicht so intensiv kümmern?

Bitte lasst mich blutigen Anfänger nicht hängen :wink:

Vielen Dank für Eure Tipps
eso
Stephanie1364
.
.
 
Posts: 3
Joined: Thu Jun 07, 2012 4:09 pm

Re: Eigene Customizingtabelle als Klasse?

Postby Helga5133 » Sun Jun 10, 2012 8:59 pm

Hi,

ich würde es folgendermaßen machen:

Wie du schon selbst schreibst, würde ich eine Klasse definieren, die deine Customizing-Tabelle als Attribut in Form einer internen Tabelle hält.
Die Bearbeitung der Tabelle (Satz einfügen, löschen, verändern etc) wird dann über Methoden realisiert.

Falls du vorher weißt, dass im Programm sehr viele Operationen auf deine Tabelle erfolgen, ist es evtl. sinnvoll im CLASS-CONSTRUCTOR erstmal die komplette Tabelle von der DB zu lesen um die Datenbank nicht mit unzähligen SELECTS zu belasten.

Da es sich scheinbar um eine Z-Tabelle handelt würde ich mich um die Persistenz selbst kümmern. Geht ja nur darum, diese eine itab wieder zurück auf die DB zu bringen. Also einfach eine Methode,
welche die bearbeitete itab zurück auf die DB schreibt.
Vorher bietet es sich wohl an, die Tabelle auf Schreibzugriffe zu sperren.

Jede Tabellenzeile zu einem eigenständigen Objekt zu machen halte ich hier nicht für sinnvoll und der Aufwand steht wohl in keinem Verhältniss.
Du müsstest erstmal aus deiner Tabelle die einzelnen Objekte erzeugen. Um diese Objekte zu halten und zu verarbeiten bräuchtest du dann wiederrum eine Klasse mit einer entsprechenden itab.

Willst du ein konkretes Objekt/Tabellenzeile bearbeiten, müsstest du dir das dann erst wieder aus der itab suchen usw.

In anderen Bereichen mag da aber durchaus wieder anders aussehen.

Gruß
Volker
Helga5133
..
..
 
Posts: 72
Joined: Wed Nov 25, 2009 5:29 pm


Return to ABAP Objects®

Who is online

Users browsing this forum: No registered users and 4 guests

cron