@Furtbichler
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
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
).
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.
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.