Komplexes Datensatzformular ohne DB-Controls

[urs.liska]

Liebe DPler und DB-Experten,

ich möchte ein relativ komplexes Datensatzformular mit verschiedenen Master-Detail-Beziehungen programmieren, ohne datengebundene Steuerelemente zu verwenden (auf einige Threads hier in der DP hin).
Dazu hätte ich ein paar Fragen, wie das am günstigsten zu realisieren wäre.

1)
Ich denke mir, ich sollte für die Daten des Datensatzes eine Klasse erstellen anstatt die Daten direkt aus einer Datenmenge in die Steuerelemente einzulesen und beim Posten wieder aus den Steuerelementen in die Paramter der Datenmenge auszulesen.
So bin ich besser für Erweiterungen (z.B. der Feld- oder Datensatzvalidierung) gerüstet, die mit Sicherheit erforderlich werden. (Ich weiß nicht, ob es für die Frage eine Rolle spielt, aber: Für das SELECT und INSERT/UPDATE der ganzen Strukturen gibt es Stored Procedures, die die ganzen Joins regeln, so dass hier relativ wenig Aufwand für die Anwendung liegt)

Ist das richtig gedacht? Oder kann ich mir den Aufwand sparen?

2)
Auf dem Formular gibt es mehrere Master-Detail-Beziehungen.
Die Detaildatensätze haben ihrerseits eine gewisse Komplexität mit Lookup-Feldern, Detaildatensätzen oder auch n:n-Datensätzen.
Ist es sinnvoll, alle diese abhängigen Daten in verschiedenen Objekten zu speichern, die wiederum über array-Eigenschaften oder TList-en verwaltet zu werden, und dann am Ende bei einem allgemeinen Post-Event alle Daten (in der entsprechenden Reihenfolge) in die DB zu schreiben?
Oder ist es besser, die Detaildaten wirklich als Datensätze zu behandeln und jeweils direkt beim Wechsel des Detaildatensatzes in die DB zu schreiben und den nächsten Datensatz aus der DB einzulesen?
Das alles unter Berücksichtigung des Planes, später einmal mehrere Instanzen des Formulars gleichzeitig öffnen zu können.

3)
Später will ich ein Datensatzauswahlformular hinzufügen.
In diesem kann über diverse Sucheinschränkungen und ein Grid ein Datensatz zur Bearbeitung ausgewählt oder der Befehl zum Einfügen eines neuen Datensatzes gegeben werden.
Das Auswahlformular soll eine Liste geöffneter Datensatzformulare verwalten.
Dazu kann ich mir verschiedene Ansätze vorstellen:
a)
Die Datensatzliste enthält Instanzen des Datensatzformulars (s.o.). In dem Datensatzformular gibt es wiederum ein Objekt mit dem eigentlichen Datensatz (s. 1).
b)
Die Datensatzliste enthält Instanzen eines Datensatz-Objekts. Dieses beinhaltet neben den eigentlichen Daten-Strukturen und den erforderlichen Methoden ein Feld mit dem Formular.

Welcher der beiden Ansätze verspricht, weniger Komplikationen nach sich zu ziehen?
Ich kann mir nicht bis ins Letzte vorstellen, welche Konsequenzen die Vorgehensweisen für die Steuerung der Anwendung letztlich haben werden.

Für Kommentare und Meinungen bin ich dankbar
MfG
Urs

[Robert_G]

Soll ich ehrlich sein?
Mache das in .Net. Dort ist jedes Control DataBinding-fähig.
DataBinding in .Net <> DB Awarenes in Delphi32!
Du bist dort nicht auf diese ollen TDataSet Descendatns angewiesen. Du kannst jede Property eine Klasse an eine "normale" Property jedes Controls packen.
Du kannst jede IList-Implementierung (somit jede Hashtable, Collection, Dictionary,...) an listenartige Controls wie ListBox, DataGrid packen.
Fasse es einfach als Appetit-macher auf und beschäftige dich ein wenig mit .Net .
Danach kannst du immer noch entscheiden, ob es auf die alte Art machst... (Wobei ich das ernsthaft bezweifle )

[Jasocul]

Delphi 6 und .Net
Ich glaube da bekommt er Probleme

[urs.liska]

Zitat von Robert_G:

Soll ich ehrlich sein?
Mache das in .Net. Dort ist jedes Control DataBinding-fähig.
DataBinding in .Net <> DB Awarenes in Delphi32!
Du bist dort nicht auf diese ollen TDataSet Descendatns angewiesen. Du kannst jede Property eine Klasse an eine "normale" Property jedes Controls packen.
Du kannst jede IList-Implementierung (somit jede Hashtable, Collection, Dictionary,...) an listenartige Controls wie ListBox, DataGrid packen.
Fasse es einfach als Appetit-macher auf und beschäftige dich ein wenig mit .Net .
Danach kannst du immer noch entscheiden, ob es auf die alte Art machst... (Wobei ich das ernsthaft bezweifle )

Hmmm
Und was sagen jetzt die TEdit-und-co-Freunde dazu?

Zitat von Jasocul:

Delphi 6 und .Net Grübelnd...
Ich glaube da bekommt er Probleme

Das muss ja nicht so bleiben

[Hansa]

Mache es so, wie du es vor hast und lasse Dich von Robert nicht verwirren. .NET muß Bytes speichern, wie die alte WinApi auch. Auf Datenbankseite wird sich nicht viel ändern und bei den Zugriffen darauf auch nicht so viel.

Lese dir das hier mal durch :

http://www.dibug.de/oop/

[Leuselator]

Habe soetwas wie Dir vorschwebt in meinem aktuellen Projekt realisiert.
Fazit vorweg: ein sehr tränenreicher Weg, extrem geil wenn Du es erstmal hast!

meine Herangehensweise:

• Entity-Objekte mit verschiedenen Attributen kapseln den Zugriff auf DB mit eigenen Methoden.
• Observer-Pattern benutzt.
• Entity-Objekte sind Observables.
• Oberflächen-Objekte zur Darstellung der Daten sind Observer, die an Observables(Entity-Objekte) gekoppelt werden.
• Änderungen in den Kontrols der Oberflächenobjekte lösen im observierten Entity-Objekt Methoden zur Validierung und abspeicherung in DB aus, anschließend werden alle Observer über die Änderung informiert.

Ist aber irre aufwändig und dauert ewig.

Vorschlag: mach es hybrid - Die KernObjekte kannst Du wie gedacht ausführen. SubAttributObjekte machst Du mit direktem BD-Zugriff.

Tel./Mail hast Du - bei näherem Interesse melde Dich.
Gruß

[urs.liska]

Zitat von Hansa:

Mache es so, wie du es vor hast und lasse Dich von Robert nicht verwirren.

Wenn ich das als zustimmende Antwort auf meine Frage 1) verstehen darf (?), habe ich immer noch keine Kommentare zu meinen Fragen 2) und 3) bekommen.
(Das ist nicht als Beschwerde an Hansa gemeint, sondern als Wiederholung der Bitte an alle).

Zitat von Hansa:

Lese dir das hier mal durch :

http://www.dibug.de/oop/

Danke für den Tipp, aber das kenne (und benutze) ich schon.

MfG
Urs

@Leuselator:
Soweit ich Dein Modell verstehe (erahne), ist das etwas entfernt Ähnliches, wie ich es auch versucht und angefangen habe. Wahrscheinlich bin ich steckengeblieben, weil ich mir nie klar war, ob ich mich letztlich in eine völlige Sackgasse manövriere, da ich es nicht auf der Grundlage erprobter Modelle (Patterns, bei denen ich mich praktisch nicht auskenne), sondern naiv von einer Frage zur nächsten stolpernd versucht habe.

Leider kann ich mir derzeit keinen langfristigen, tränenreichen Weg leisten, auch wenn ich grundsätzlich sehr interessiert wäre.
Daher scheint mir die hybrid-Version auch als gangbarer Weg

Ich habe mich nicht nach Neujahr gemeldet, weil ich meinen Abgabetermin überziehen musste (und durfte . Und danach steht dann eben durch die Verzögerung der nächste schon wieder vor der Tür...
(A propos: Wie steht es mit dem Büro am PoPl? Darfst Du noch hin, wenn man fragen darf?)

MfG
Urs