AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi Übergabe Datenbankschnittstelle (Transaction, etc.)

Übergabe Datenbankschnittstelle (Transaction, etc.)

Ein Thema von Artur · begonnen am 3. Jan 2014 · letzter Beitrag vom 5. Jan 2014
Antwort Antwort
Seite 2 von 2     12
Furtbichler
(Gast)

n/a Beiträge
 
#11

AW: Übergabe Datenbankschnittstelle (Transaction, etc.)

  Alt 5. Jan 2014, 14:29
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
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.658 Beiträge
 
Delphi 7 Personal
 
#12

AW: Übergabe Datenbankschnittstelle (Transaction, etc.)

  Alt 5. Jan 2014, 14:54

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
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
nahpets
(Gast)

n/a Beiträge
 
#13

AW: Übergabe Datenbankschnittstelle (Transaction, etc.)

  Alt 5. Jan 2014, 15:28
@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.

Geändert von nahpets ( 5. Jan 2014 um 15:38 Uhr) Grund: Edit hat Schreibfehler gefunden...
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:18 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf