Datasource/Table global?

[NoGAD]

Hallo,

ich habe mein kleines Projekt nun auf zwei VCL-Forms verteilt.

Wie spricht man in gutem Programmierstil die Datenbankobjekte an?

DataSource1 und Table1 auf das Hauptformular (Form1) und in Form2 das in die Uses mit aufnehmen, um dann im Code

Form1.DataSource1. ... anzusteuern?

LG Mathias

[haentschman]

Moin...8-)

Zitat:

gutem Programmierstil

Guter Programmierstil ist neuerdings:
1. Die Logic von der Oberfläche zu trennen. In die Logic gehört auch der Zugriff auf die Datenbank.
2. keine datenbankensitiven Komponenten mehr benutzen...:zwinker:

Vorschlag 1:

Form - Unit Logic - Datamodule/Interface/Unit für den Zugriff
Jeder kennt sein "Kind". Die Form kennt die Logic. Die Logic kennt den Zugriff. Rückwärts laufen die Informationen über Events.


Vorschlag 2:
Klassisch: Form - Datamodule

:wink:

Zitat:

Form1.DataSource1

:kotz:Bitte verwende vernünftige Namen... Auch wenn es schwer ist die automatische Vergebung nochmal zu ändern. PS: Dafür gibt es Tools, die nach dem Plazieren anbieten den Namen zu ändern...mit Präfix. :thumb: (CnPack)

[Lemmy]

Zitat:

Zitat von haentschman (Beitrag 1481973)

Moin...8-)

Zitat:

gutem Programmierstil

Guter Programmierstil ist neuerdings:
1. Die Logic von der Oberfläche zu trennen. In die Logic gehört auch der Zugriff auf die Datenbank.

Nope. die (Fach)Logik des Programms gehört (wenn schon) in einen Bereich, der weder von Oberflächenkomponenten noch von Datenbankzugriffen "verseucht" ist, damit der testbar ist.

[haentschman]

Zitat:

die (Fach)Logik des Programms gehört (wenn schon) in einen Bereich, der weder von Oberflächenkomponenten noch von Datenbankzugriffen "verseucht"

...ich meinte erst mal nicht auf die Form! :zwinker:

Zitat:

Form - Unit Logic - Datamodule/Interface/Unit für den Zugriff

[TigerLilly]

Zitat:

Zitat von haentschman (Beitrag 1481973)

2. keine datenbankensitiven Komponenten mehr benutzen...:zwinker:

Oft behauptet, aber wenig wahr. Es stimmt, alles auf ein Form zu klatschen von TdbEdit bis hin zur DB-Verbindung ist nicht so gut (aber auch da gibt es Ausnahmen). Letztlich ´gibt es diese Layer:
- visuelle Darstellung, UI
- Validierung (die trenne ich noch gern in UI bezogene + Business Validierung)
- Business Logic
- Datenbereitstellung

Wenn man das vernünftig trennt, spricht - für mich - nichts gegen datensensitive Controls.

[RSF]

Zitat:

Zitat von TigerLilly (Beitrag 1481988)

Wenn man das vernünftig trennt, spricht - für mich - nichts gegen datensensitive Controls.

So sehe ich das auch. :thumb:

[NoGAD]

Danke für eure Anregungen.

Kleine Rückfrage:

Wenn ich in einer Form ein Objekt dynamisch, also während der Laufzeit erstelle, gehört das dann doch in den Kontext der Form.

Erstelle ich das jedoch in einer eigenen Unit, wird es ein Globales Objekt.

Nun wird mir immer wieder erklärt, dass Globale Variablen/Objekte usw. ganz teuflisch und absolut böse sind. Warum ist das in diesem Fall dann anders?

Zitat:

Zitat von haentschman (Beitrag 1481973)

Zitat:

Form1.DataSource1

:kotz:Bitte verwende vernünftige Namen... Auch wenn es schwer ist die automatische Vergebung nochmal zu ändern. PS: Dafür gibt es Tools, die nach dem Plazieren anbieten den Namen zu ändern...mit Präfix. :thumb: (CnPack)

Das war doch nur ein Beispiel. (augenroll) ;-)

LG Mathias

[stahli]

Zitat:

Zitat von NoGAD (Beitrag 1482038)

Nun wird mir immer wieder erklärt, dass Globale Variablen/Objekte usw. ganz teuflisch und absolut böse sind. Warum ist das in diesem Fall dann anders?

Globale Variablen sind kein Teufelswerk, können aber Fehler provozieren.

Mal ein ganz schlechtes Beispiel:
Du hast eine globale Variable I, und speicherst dort Deinen Kontostand.
In irgendeiner Methode lässt Du eine Schleife von 0 bis 1000 laufen und benutzt die Schleifenvariable I.
Du hast aber vergessen, die lokale Variable I anzulegen, so dass Deine Kontovariable von 0 bis 1000 erhöht wird.
Ob das jetzt gut oder schlecht ist, musst Du selbst entscheiden. ;-)

Also man muss ggf. aufpassen, dass man globale Variablen vernünftig nutzt, dann ist eigentlich nichts dagegen einzuwenden. Es kann aber auch schnell mal was dabei schief gehen.

[NoGAD]

Zitat:

Zitat von stahli (Beitrag 1482043)

Zitat:

Zitat von NoGAD (Beitrag 1482038)

Nun wird mir immer wieder erklärt, dass Globale Variablen/Objekte usw. ganz teuflisch und absolut böse sind. Warum ist das in diesem Fall dann anders?

Globale Variablen sind kein Teufelswerk, können aber Fehler provozieren.

Mal ein ganz schlechtes Beispiel:
Du hast eine globale Variable I, und speicherst dort Deinen Kontostand.
In irgendeiner Methode lässt Du eine Schleife von 0 bis 1000 laufen und benutzt die Schleifenvariable I.
Du hast aber vergessen, die lokale Variable I anzulegen, so dass Deine Kontovariable von 0 bis 1000 erhöht wird.
Ob das jetzt gut oder schlecht ist, musst Du selbst entscheiden. ;-)

Also man muss ggf. aufpassen, dass man globale Variablen vernünftig nutzt, dann ist eigentlich nichts dagegen einzuwenden. Es kann aber auch schnell mal was dabei schief gehen.

Danke :-)