Fragen zum Klassendesign bzgl. Persitenz

[Jumpy]

Hallo,

ich brauche einmal Hilfe/Anregungen beim Design von ein paar zusammenhängenden Klassen, insbesondere dabei, die Objekte nachher zu speichern, also bei der Persitenz. Es geht um das Kopieren, Verschieben, Zippen, Verschicken von immer gleichen Dateien.
Ich hab vor ca. 2 Wochen recht interessiert den MVC-Thread gelesen und will versuchen, GUI-Logik-Daten zu trennen.

1)
Es soll eine (abstrakte?) Oberklassen geben TJob.
Felder sowas wie: ID, Name, Ersteller, Letztes Ausführdatum, ...
Funktionen, die wahrsch. alle überschrieben werden: Laden, Speichern, Prüfen, Ausführen
Von der erben:

2)
Eine Klasse TFileJob für das speichern mehrerer hintereinanderauszuführender einfacher (Copy,Move,delete) Dateioperationen, wo jeweils eine Nummer (= ID?) für die Reihenfolge, Die Art der Operation und als String Quellpfad&Name und Zielpfad&Name gespeichert werden muss.

3)
Eine Klasse TZipJob, wo es eine Zieldateipfad&name gibt und mehrere Quelldateien(Pfad+Name), die
gespeichert werden.

4)
Eine Klasse TMailJob wo zunächste eine Liste von Quelldateien gespeichert wird und dann diverse Infos, die zum Mailversand wichtig sind: Empfänger, Betreff, usw.

Mein Hauptproblem ist nun, wie ich diese unterschiedlichen Jobs lade/speichere. Kann dazu natürlich zu jeder Klasse die passende Speichermethode in der Klasse überschreiben.
Ich hab aber noch die Vision, irgendwie eine eingen Klasse zu haben, die das Speichern übernimmt und die z.B. auch erstmal nur eine Liste der vorhandenen Jobs erstellen kann, ohne das gleich alle Jobs in den Speicher geladen werden müssen. Auch wäre es schön, das so nur an einer Stelle etwas verändert werden muss, wenn mal das "Speichermedium" gewechselt wird, z.B. von einer DB auf Ini-Datei(en) o.ä., bzw. vllt. bietet diese Klasse von vorneherein unterschiedl. Speichermöglichkeiten an.

Die Frage ist nun, wie könnte man sowas realisieren, da gibt es doch bestimmt irgendwelche Muster oder Prinzipien? Würde eine solche Klasse auch noch Hilfsklassen brauchen (Speicher in Ini, Speichern in DB,...)?

Dann geht es noch um die GUI. Für die Anzeige/Editiermöglichkeit jeder Jobart würde ja eine leicht andere Oberfläsche gebraucht. Wie würde man das realisieren? Eine Oberfläsche(=Form), die sich anpasst oder unterschiedliche Forms? Vllt. mit Frames?

Und mir ist noch nicht ganz klar, wo die Controler-Klasse in das Bild passt.

[Alaitoc]

Nun was mir so spontan dazu einfällt...

Als Erstes hast du eine Factory, die je nach JobTyp ein Datenobjekt und ein GUI erzeugt. Diese könntest du dann z.b. per MVC miteinander koppeln.

Sobald die Daten in der GUI eingegeben wurden und der Controller die Daten ins Datenobjekt übernommen hat, könntest du dann das Datenobjekt an den "DeviceManager" oder so übergeben.

Dieser entscheidet dann je nach Datenobjekt, welche Schnittstelle benötigt wird und delegiert das an das "Device", also z.B. den Zip-Ersteller.

Fazit:
- Factory: Die Datenobjekte und GUI's bereitstellt, sowie mit dem Controller verknüpft. (Factory)
- Datenobjekt: Abstraktes Objekt, sowie spezifische Objekte (Model)
- GUI: Abstrakte GUI, sowie spezifische GUI (View)
- Controller: Verwaltet die Datenübergabe zwischen GUI und Datenobjekten (Control)
- DeviceManager: Kann Datenobjekte annehmen und erstellt dann das Device und delegiert es weiter (Factory)
- Device: Regelt die Datenverarbeitung

Grundsätzlich sollte das so klappen...glaube ich

MfG Alaitoc

[stahli]

@Jumpy
Stimmt Dein D6 Ent. noch?
Wäre dann ein Upgrade auf 2010/XE denkbar? Hier sollte die neue RTTI und die Attribute Dein Vorhaben deutlich vereinfachen...

[Alaitoc]

@stahli

Kannst du mal ein Beispiel geben, wie sie das erleichtern können?

Mich würde das nämlich dann auch interessieren, da ich wenn überhaupt nur D7 zur Verfügung habe :/

MfG Alaitoc

[Lemmy]

Hi,

wer sich für den "alten" Weg interessiert schaue sich das hier kurz an:
http://delphitutorials.de/node/20

wer sich mehr für den neuen Weg interessiert, dem sei das Delphi 2010 Handbook von Marco Cantu empfohlen http://sites.fastspring.com/wintechi...source=webpage kostet als EBook 21€.

vereinfacht gesagt: Vorteil des neuen Wegs ist der Zugriff auf die Eigenschaften per Klassenmodell. Weiterhin sind auch private und öffentliche Felder auslesbar (beim alten Weg nur published).

Grüße

[Alaitoc]

Ah Serialisierung in Delphi, was es nicht alles gibt ^^'

Naja als Delphi7-Nutzer ist mir das gar nicht in den Sinn gekommen, hab ich bisher nur bei C# genutzt...aber schön das es scheinbar einen "alten" Weg gibt. Werde ich mir bei Zeiten mal anschauen.

Danke dir bzw. euch

MfG Alaitoc

[Jumpy]

Ja danke auch schonmal für den Denkansatz. Das muss ich mir aber noch mehrfach mit Verstand durchlesen, wie das alles gemeint ist. Speziell, wie du das mit der Factory meinst (hab da erstmalig vor kurzem in einem OOP Buch drüber gelesen und da gabs das sowohl als Pattern, Klasse, Funktion und immer mit leicht anderer Idee dahinter).

@stahli
Gedacht ist eigentlich die Umsetzung in Delphi6.
Delphi2010 ist zwar auch vorhanden, aber da darf ich nicht immer dran.
Zudem müsst ich mich in RTTI auch erstmal einlesen, da glaub ich hier im Hause noch keiner was damit gemacht hat. Wäre vllt. mal ein Grund damit anzufangen.

[stahli]

Mit der neuen RTTI kann man Klassen und Objekte untersuchen, welche Felder, Propertys und Methoden existieren und diese dann auch benutzen.
Mit Attributen kann man Klassen und deren Elementen zusätzliche "Tags anheften" und diese später auslesen.

So kann man z.B. bestimmten Eigenschaften (z.B. FirstName + LastName) ein Attribute [DATA] zuweisen.
Später kann man alle Eigenschaften suchen, die solch ein Attribut haben und deren Werte speichern bzw. lesen.
Das kann dann eine Funktion übernehmen, der man dann irgendein beliebiges Objekt übergeben kann. Das erspart schon eine Menge Arbeit und bietet viele neue Möglichkeiten gegenüber den alten Lösungen.