AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Klassendesign und Logik

Ein Thema von stOrM · begonnen am 2. Mär 2019 · letzter Beitrag vom 6. Mär 2019
Antwort Antwort
Seite 1 von 2  1 2   
Benutzerbild von stOrM
stOrM

Registriert seit: 7. Jun 2003
Ort: Mülheim an der Ruhr
424 Beiträge
 
Delphi 10.3 Rio
 
#1

Klassendesign und Logik

  Alt 2. Mär 2019, 11:59
Moin,
ich hab mir gerade eine Klasse erstellt, welche Felder einer Tabelle abbilden soll.
Der Grund war, dass ich die eigentliche GUI nur noch zum anzeigen der Daten verwenden will, was mit jedem x-beliebigen Control sein könnte.

Meine Frage wäre jetzt wie bekommt die Klasse mit, dass der Benutzer einen Wert in einem Feld geändert hat, so das wir z.B. ein entsprechendes Update in dieser Klasse, für die Tabelle aufrufen könnten (Ist-Wert entspricht nicht mehr Eingangswert, da müssten ja irgendwie beide Werte vorgehalten werden?)

Sicherlich könnte man da jetzt irgendwas auf die schnelle mit Events zusammenschustern, aber ich würde gern hören, wie Ihr so etwas löst? Vermutlich wesentlich eleganter...
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.626 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#2

AW: Klassendesign und Logik

  Alt 2. Mär 2019, 12:12
Kommt immer ein wenig drauf an. Bewährte Konzepte, welche auch der Trennung von GUI, Business-Logik und Daten dienen sind z.B. MVC oder MVVW. Von der Umsetzung her könnte man unter Delphi z.B. auf DataBindings setzen .. Events sind aber definitiv auch eine legitime Möglichkeit.

Nachtrag:
Oft sind die genannten Konzepte aber etwas starr und zumindest für kleine- bis mittelgroße Projekte mehr Last als von Nutzen. Bezüglich der Wert-Änderung, mache ich das meistens in meiner Model Klasse (deiner Entität, welche die Datenbank-Tabelle abbildet). Dort läuft das bei mir dann über Setter Funktionen der Art:
Delphi-Quellcode:
type
  TModel = class(TObject)
  strict private
    FX: Integer;
  public
    ...
  public
    property X: Integer read FX write SetX;
  end;

...

procedure TModel.SetX(const X: Integer);
begin
  if (FX <> X) then
  begin
    FX := X;
    RaiseUpdateEvent;
  end;
end;
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)

Geändert von Zacherl ( 2. Mär 2019 um 12:15 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von stOrM
stOrM

Registriert seit: 7. Jun 2003
Ort: Mülheim an der Ruhr
424 Beiträge
 
Delphi 10.3 Rio
 
#3

AW: Klassendesign und Logik

  Alt 2. Mär 2019, 12:36
Kommt immer ein wenig drauf an. Bewährte Konzepte, welche auch der Trennung von GUI, Business-Logik und Daten dienen sind z.B. MVC oder MVVW. Von der Umsetzung her könnte man unter Delphi z.B. auf DataBindings setzen .. Events sind aber definitiv auch eine legitime Möglichkeit.

Nachtrag:
Oft sind die genannten Konzepte aber etwas starr und zumindest für kleine- bis mittelgroße Projekte mehr Last als von Nutzen. Bezüglich der Wert-Änderung, mache ich das meistens in meiner Model Klasse (deiner Entität, welche die Datenbank-Tabelle abbildet). Dort läuft das bei mir dann über Setter Funktionen der Art:
Delphi-Quellcode:
type
  TModel = class(TObject)
  strict private
    FX: Integer;
  public
    ...
  public
    property X: Integer read FX write SetX;
  end;

...

procedure TModel.SetX(const X: Integer);
begin
  if (FX <> X) then
  begin
    FX := X;
    RaiseUpdateEvent;
  end;
end;

Genau das was ich im Kopf hatte als ich den Eingangspost erstellt hatte.
MVC oder MVVW wäre vermutlich am besten allerdings sehe ich das genau wie Du, für so ein kleines Projekt ziemlicher Overkill, was sicherlich auch wieder Ansichtssache sein kann.

Wie machst Du danach dein Update? Übergibst Du für dein Update SQL nur die Felder die tatsächlich geändert wurden oder machst Du ein Update aller Felder für den entsprechenden Datensatz?
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.626 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#4

AW: Klassendesign und Logik

  Alt 2. Mär 2019, 15:49
Wie machst Du danach dein Update? Übergibst Du für dein Update SQL nur die Felder die tatsächlich geändert wurden oder machst Du ein Update aller Felder für den entsprechenden Datensatz?
Das kommt denke ich ein wenig auf den Anwendungsfall an und vermutlich auch darauf wie viele Felder dein Model hat. Ich arbeite unter Delphi nicht wirklich mit Datenbanken, deshalb kann ich dir da nicht allzu viel zu sagen.
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
1.093 Beiträge
 
Delphi 7 Professional
 
#5

AW: Klassendesign und Logik

  Alt 2. Mär 2019, 17:32
Wir nutzen da als "Schnittstelle" je Maske/Formular zwei Methoden:

Eine, um aus dem Objekt die Daten in das Formular zu bekommen und eine, um die Daten aus dem Formular in das Objekt zu bekommen.

Da die Daten datenbankseitig grundsätzlich historisiert/versioniert werden, stellt sich die Frage, ob nur im Formular veränderte Daten übernommen oder alle, nicht.

Jedes Attribut der Klasse hat ein entsprechendes "Gegenstück" im Formular.

Ob man jetzt Plausibilitätsprüfungen in diesen Methoden vornimmt oder in den Settern des Objektes, ist ein bisserl Geschmacksfrage.

Werden Plausibilitätsprüfungen auch benötig, wenn die Daten aus anderen Quellen, als der Maske, übernommen werden, bieten sich die Setter an.

Eventuell erforderliche Typkonvertierungen zwischen Objektattribut und Anzeigecontrol finden in den beiden Methoden statt.
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.252 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#6

AW: Klassendesign und Logik

  Alt 3. Mär 2019, 06:44
Wie Zacherl schon sagte, kommt es auf den Umfang der Tabelle (also wieviele Felder) an. Bei kleinen Tabellen, würde ich persönlich gleich alle Felder Updaten.

Bei großen Tabellen, könnte man z.B. in den Settern ein Flag setzten, und beim Update diese Abfragen und so das Statement zusammenbauen.
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
Schokohase
(Gast)

n/a Beiträge
 
#7

AW: Klassendesign und Logik

  Alt 3. Mär 2019, 07:18
Das hat doch mit dem Umfang der Tabellen nichts zu tun, sondern mit dem Kontext, bzw. wie du Kollisionen entdecken kannst.

Ganz einfaches Beispiel:

Original steht in der DB
Code:
Strasse: Holzweg 3
Ort: Walden
User 1 ändert und speichert
Code:
Strasse(*): Holzpfad 7
Ort: Walden
User 2 ändert und speichert
Code:
Strasse: Holzweg 3
Ort(*): Waldihausen
Heraus kommt jetzt
Code:
Strasse: Holzpfad 7
Ort: Waldihausen
und diese Daten hat kein User jemals so abgesegnet.
  Mit Zitat antworten Zitat
ConstantGardener

Registriert seit: 24. Jan 2006
Ort: Halberstadt
335 Beiträge
 
Delphi 10.3 Rio
 
#8

AW: Klassendesign und Logik

  Alt 3. Mär 2019, 08:22
@Schokohase

...na das ist ja dann erst die nächste Baustelle! Der TE hatte noch nichts von MultiUser Umgebung geschrieben, es ging erstmal nur um die Datenhaltung im Objekt usw.

@Storm
Im Prinzip suchst du ja nach einem ORM. Ob du das vom Umfang her benötigst kannst Du nur selbst entscheiden.
Andreas Schachtner
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.252 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#9

AW: Klassendesign und Logik

  Alt 4. Mär 2019, 03:48
Das hat doch mit dem Umfang der Tabellen nichts zu tun, sondern mit dem Kontext, bzw. wie du Kollisionen entdecken kannst.
Öhm...dafür gibts sowas wie PrimaryKeys bzw. Unique index, um einen DS eindeutig zu identifizieren. Dein Beispiel läst sich mit einer Plausibilitätsprüfung vermeiden, und hat an und für sich nix mit der DB zu tun.
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
Schokohase
(Gast)

n/a Beiträge
 
#10

AW: Klassendesign und Logik

  Alt 4. Mär 2019, 07:20
Das hat doch mit dem Umfang der Tabellen nichts zu tun, sondern mit dem Kontext, bzw. wie du Kollisionen entdecken kannst.
Öhm...dafür gibts sowas wie PrimaryKeys bzw. Unique index, um einen DS eindeutig zu identifizieren. Dein Beispiel läst sich mit einer Plausibilitätsprüfung vermeiden, und hat an und für sich nix mit der DB zu tun.
Dann hast du mich nicht verstanden.

Der Datensatz mit der ID 1 wird von zwei Benutzern gleichzeitig so wie beschrieben verändert. Wenn jetzt nur die Änderungen der Benutzer gespeichert werden, dann kommt dieser Unsinn heraus.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

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 02:25 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf