Datenbankzugriffe kapseln oder verteilen?

[Taladan]

Ich werde unterschiedliche Forms haben, die alle auf die Datenbank zugreifen werden. Viele haben ähnliche Aufgaben und somit muß ich vieles doppelt deninieren. Was auch bedeutet das ich mehrere fbconnection, Datasets und fbadaptoren einfach doppelt definieren muß. Wäre es da Sinnvoll diese auf einer Form/Unit zu kapseln und sich von dort die Daten dann zu holen?

[angos]

Ich sehe das eigentlich als sehr sinnvoll.
Aber pack die dann nicht auf eine Form sondern direkt in ein Datenmodul

[mschaefer]

Ja,

Nimm die Datenbankanbindungskomponenten auf ein DataModule-Formular. Diese Unit bindest Du in alle anderen Fensterunits ein.
Damit hast Du bei jedem Formular, welches Du aufrufst, den gleichen Datensatz angezeigt, da die Query schon im OnCreate des Datmodules auf active gestellt werden kann.

Die Verfahrensweise ist dann Sinnvoll, wenn Du ein Übersichtsformular (Liste) und mehrere Bearbeitungsformulare (Editfelder ) zusammenstellst. Hier kann dann aus der Liste in die Bearbeitungsformulare gesprungen werden und man hat den in der Liste gewählten Datensatz zur Bearbeitung. Sowas wird auch gerne in MDI-Konzepten verwendet.

Grüße // Martin

[Taladan]

Und wie nennt sich ein Datenmodul in .Net? In Win32 kenne ich diese Datenmodule aber in .Net ist mir das noch nicht begegnet...

[Taladan]

Wären evtl UserControls eine möglichkeit dafür?

[MagicAndre1981]

Zitat von Taladan:

Und wie nennt sich ein Datenmodul in .Net? In Win32 kenne ich diese Datenmodule aber in .Net ist mir das noch nicht begegnet...

Mach doch ein Assembly, dass den ganzen Zugriff kapselt. Da packst du alles rein, was du brauchst. Eine Methode, die einen DataReader, eine DataTable, ein DataSet zurückgibt und alles was du sonst noch brauchst.

[Taladan]

Was ist ein Assembly? In meinen Buch ist die nicht beschrieben.

[Robert_G]

Schaue dir zum Beispiel nHibernate an.
Aber willst mir nach all der Zeit mit .Net ernsthaft weißmachen, dass du keine Assemblies kennst?
Könntest du vllt den Namen des .Net-Buches nennen, das gehört anscheinend auf die Liste der Bücher, die die Welt nicht braucht.

btw: Das was ein DataModule ausmacht hast du mit einer CustomComponent.
Eine Datei, die eine Klasse enthält, die von Component ableitet sollte dir in der IDE automatisch den nonvisual Designer zeigen. Da kannst du dann andere Komponenten draufwerfen und deren Werte bestzen. Wenn du im Code noch ein paar Attribute setzt kannst du sie als eine DataSource in UserControls und formularen benutzen.
Das was DataModules in Delphi32 beliebt gemacht hat, existiert schlichtweg in .Net nicht mehr. Die alten Dinger waren nur als globale Variablen im Designer verwendbar...

[Taladan]

Ok. Dann mache ich das über eine eigene Komponente. Dazu eine Frage, wo packe ich dann Sachen rein, die normalerweise in das OnCreate Ereignis des Formulars gehören, aber nu mit in die Komponente gehören. Zum Beispiel DataRelation´en.

Zum Buch: Delphi 2005 von Elmar Walken. Hier sind Assemblies nur kurz angeschnitten. Hier steht es zusammengefasst so (mindestens der Teil, der für mich verständlich ist), das ein Assembly eine fertige .dll oder .exe ist. Diese zu Namespaces zusammengefasst werden und zur Laufzeit genutzt wird.
Was mir aber nicht viel weiter hilft. Da ich es so verstehe, das ich ein Programm schreiben muß, um ein anderes zu bedienen, was ich ähm nicht sinnvoll ansehe.

[Taladan]

Dazu eine Frage, wo packe ich dann Sachen rein, die normalerweise in das OnCreate Ereignis des Formulars gehören, aber nu mit in die Komponente gehören? Zum Beispiel DataRelation´en.

*push*