Übergabe Datenbankschnittstelle (Transaction, etc.)

[nahpets]

Hallo Artur,

Zitat von Artur:

Wie ist bei dir Kopplung der Eingabeelemente mit der Datenbank gelöst?
Je nach Datensatz (z.B. Kontaktdaten), kommen ja einige Felder zusammen (Kurzname/Matchcode, Firma, Strase, PLZ, Ort, Telefon, Telefax, Mobilrufnummer, Art der Firma, Bedeutung, usw.).

Hast du das alles in einer Klasse gekapselt?
Und wie ist es, wenn Grids gewünscht sind?

Wenn Du datensensitive Elemente nutzen möchtest oder musst, hast Du zwei(?) Möglichkeiten:

Entsprechende DataSource ins Datenmodul und der Komponente dann im Objektinspektor bei DataSource Datenmodul.Datasource zuordnen.

Oder:

DataSource auf das Formular und dort dann im Objektinspektor bei Dataset Datenmodul.Query zuordnen.

Zitat von Artur:

Datensensitive Elemente sind ja vermutlich tabu, wenn du die Datenbank komplett gekapselt hast.

Exakt so ist es.

Wir nutzen für die "Datenhaltung" eigentlich ganz gerne Klassen. Die Klasse enthält alle Daten eines Datensatzes, also ein Objekt.

Die Formulare enthalten je Klasse eine Methode ObjektInMaske (also die Übertragung in die Anzeigefelder...) und eine Methode MaskeInObjekt für die Übertragung der Anzeigedaten in die Attribute der Klasse. Änderungs- bzw. Erfassungsmaske enthalten gewöhnlich nur die Daten einer Klasse: also je Klasse eine Maske. In Masken, die Daten mehrere Klassen anzeigen ist eine Änderung nicht möglich. Zum Ändern wird halt die "Änderungsmaske" angezeigt. Eventuell kann man in der Änderungsmaske auch Daten anderer Klassen zur Information anzeigen, das kommt aber sehr auf den Einzelfall an.

Datenänderung in Grids... sind "bahh". Wenn wir "unsauber" Daten aus der DB in einem DBGrid... anzeigen, dann nur Readonly.

Sonstige Grids werden aus einer Abfrage per "While Not Eof" befüllt. Dabei wird immer der technische Schlüssel mit ins Grid übernommen. Die entsprechende Spalte bekommt die Breite 0 oder wird sonstwie unsichtbar gemacht (es sei den, der technische Schlüssel hat für die Anwender eine Bedeutung - z. B. Aktenzeichen, Bestellnummer, Kundennummer...). Ein Doppelklick auf das Grid holt über diesen technischen Schlüssel die Daten aus der Datenbank und überträgt sie in die Klasse. Die Klasse sorgt dann per ObjektInMaske für die Anzeige. Beim Verlassen der Maske werden die Daten (sofern erwünscht) per MaskeInObjekt übernommen oder verworfen, halt abhängig von der Art, wie die Anzeige verlassen wird (ok/speichern/abbrechen...).

[Artur]

Nochmal vielen Dank für die Tipps an alle und insbesondere an nahpets.

Zum Teil habe ich es in meinem Kalendermodul auch so ähnlich umgesetzt, weil ich den fertigen TMS Kalender genommen habe (nicht die DB Version).
Ich habe jetzt einiges zum Nachdenken und werde schauen, ob ich das bei zukünftigen Modulen noch mehr in die Richtung umsetzen kann.

Ciao,

Artur

[Furtbichler]

Zitat von nahpets:

Die Formulare enthalten je Klasse eine Methode ObjektInMaske ...und eine Methode MaskeInObjekt ...

Wieso nicht: Pro Klasse ein TFrame? Dann kannst Du auch in Formularen ändern, die mehrere Klassen anzeigen.

Zitat:

Datenänderung in Grids... sind "bahh".

Verstehe ich nicht. Sag das mal einem Sachbearbeiter, der täglich 1000 Datensätze korrekturlesen und korrigieren soll.

Ach, ihr habt kein richtiges Grid, oder? Na dann... ok. Grundvoraussetzung ist natürlich ein ordentliches Grid (DevExpress, was sonst? . Damit geht das dann richtig schnell, sehr komfortabel und genau in der Architektur, die ihr umgesetzt habt. So ein Grid eignet sich natürlich nicht dafür, sehr viele Daten abändern zu können, aber die *Option* sollte schon da sein.

Ich hatte einen 'Head of Development', der sah das genauso wie Du: Grids sind readonly und zum Ändern muss man doppelklicken und dann poppt ein Dialog hoch. Bei Grids mit drei Spalten, wobei nur eine änderbar ist (ne Checkbox) ist dieses 'bahh' dann extrem peinlich und degeneriert zu einer Lachnummer

[p80286]

Zitat von Furtbichler:

Zitat:

Datenänderung in Grids... sind "bahh".

Verstehe ich nicht. Sag das mal einem Sachbearbeiter, der täglich 1000 Datensätze korrekturlesen und korrigieren soll.

Das ist ein Mißverständnis. Der Sachbearbeiter darf in einem Grid soviel ändern wie er will, aber das Grid ist nur für die Oberfläche zuständig. Die Datenänderung läuft nur über die davon unabhängige Schnittstelle.
Darum "ist ein DBGrid bäh"

Gruß
K-H

[nahpets]

@Furtbichler

Zitat von Furtbichler:

Zitat von nahpets:

Die Formulare enthalten je Klasse eine Methode ObjektInMaske ...und eine Methode MaskeInObjekt ...

Wieso nicht: Pro Klasse ein TFrame? Dann kannst Du auch in Formularen ändern, die mehrere Klassen anzeigen.

Ja klar, wäre eine sinnvolle Alternative. Das Grundkonzept entstand halt nicht unter Delphi, sondern mit einer Entwicklungsumgebung, bei der ich mich bis heute weigere sie ernsthaft als solche zu bezeichnen Die IDE war halt sehr rudimentär, aber das Konzept war damit trotzdem hervorragend umzusetzen und blieb (trotz jahrzehntelanger - inzwischen ca. 25 Jahre - Weiterentwicklung und Anpassung) gleichbleibend gut pfleg- und wartbar. Haben es dann halt konsequent auch in anderen Entwicklungsumgebungen genutzt (sei es halt Delphi, Java, C#, ...)

Zitat von Furtbichler:

Zitat von nahpets:

Datenänderung in Grids... sind "bahh".

Verstehe ich nicht. Sag das mal einem Sachbearbeiter, der täglich 1000 Datensätze korrekturlesen und korrigieren soll.

Das sehen die Sachbearbeiter halt oft anders, als die "Fachleute", die die Vorgaben machen . Habe selbst lange in der Sachbearbeitung gearbeitet (die Softwareentwicklung kam erst später dazu) und in einem guten Grid kann man extrem schnell arbeiten. Und wenn ich heute mal wieder den "Job erbe: Kannst Du mal die Daten in Ordnung bringen", dann baue ich mir notfalls ein Miniprogramm mit 'nem Grid, damit es einfach und schnell geht. Bin da konsequent inkonsequent .
Braucht man aber bei Änderungen eine Versionierung, dann wird das mit einem Grid recht schnell schwierig, wenn man darunter eine Datenbank hat, mit der man das nicht realisieren kann oder darf. Wir hatten halt häufiger die Vorgabe, alle Geschäftslogik im Programm abzubilden, um datenbankunabhängig zu sein. Sprich: Datenbank nur zur reinen Datenhaltung und keinerlei Logik dort ablegen (über die Sinnhaftigkeit läßt sich hervoragend streiten ).

Zitat von Furtbichler:

Ach, ihr habt kein richtiges Grid, oder? Na dann... ok. Grundvoraussetzung ist natürlich ein ordentliches Grid (DevExpress, was sonst? . Damit geht das dann richtig schnell, sehr komfortabel und genau in der Architektur, die ihr umgesetzt habt. So ein Grid eignet sich natürlich nicht dafür, sehr viele Daten abändern zu können, aber die *Option* sollte schon da sein.

Ja, es kommt immer auf den Sachverhalt an. Bei einfachen Adressdaten ist ein Grid sicherlich ausreichend und komfortabel. Werden aber im Grid Daten per View aus mehreren Tabellen angezeigt, die letztlich zu unterschiedlichen Objekten gehören, so wird das Ändern im Grid eventuell doch mal etwas schwieriger. In einer eigenen Maske kann man dann halt die Daten eines Objektes ändern und dabei die Referenzen auf andere Objekte in Nachschlagtabellen (Comboboxen...) zur Auswahl anbieten. Hat man ein Objekt, das über eine Vielzahl von Fremdschlüsseln Werte aus diversen Schlüsseltabellen referenziert, dann wird das in 'nem einfachen DBGrid doch eher schwierig mit der Pflege.

Zitat von Furtbichler:

Ich hatte einen 'Head of Development', der sah das genauso wie Du: Grids sind readonly und zum Ändern muss man doppelklicken und dann poppt ein Dialog hoch. Bei Grids mit drei Spalten, wobei nur eine änderbar ist (ne Checkbox) ist dieses 'bahh' dann extrem peinlich und degeneriert zu einer Lachnummer

Na klar, das Grundkonzept kann, extrem konsequent durchgesetzt, durchaus zu absurden Folgen führen.

Zitat von p80286:

Das ist ein Mißverständnis. Der Sachbearbeiter darf in einem Grid soviel ändern wie er will, aber das Grid ist nur für die Oberfläche zuständig. Die Datenänderung läuft nur über die davon unabhängige Schnittstelle.
Darum "ist ein DBGrid bäh"

Sowas hatten wir auch schon, Daten aus der DB in ein TStringgrid einlesen, dort dürfen die Sachbearbeiter in einigen Spalten machen was sie wollen, andere Spalten werden bei Änderungen sofort neu berechnet, falblich verändert, Unplausibilitäten kenntlich gemacht... und anschließend, wenn's ok ist, ab damit in die Datenbank.

Mein Fazit ist bisher eigentlich: Das immer gültige Konzept für die Umsetzng von Software gibt es nicht. Innerhalb einer Software sollte man aber das gewählte Konzept möglichst konsequent umsetzen. Das von mir zitierte Konzept bietet sich halt bei sehr komplexer Geschäftslogik an, bei der (fast) jede Änderung an einem Objekt Auswirkung(en) auf andere Objekte hat oder Plausibilitäten (ggfls. quer durch das ganze System) zu prüfen sind. Bei reiner Datenhaltung (annähernd) ohne Geschäftslogik ist es absurd.