Dataset global im Programm verfügbar machen

  • VB.NET

Es gibt 10 Antworten in diesem Thema. Der letzte Beitrag () ist von TS71M.

    Dataset global im Programm verfügbar machen

    Hi,

    die Frage ist wahrscheinlich blöd, aber ich komm net drauf:

    Ich arbeite mit einem streng typisierten Dataset. Bisher läuft es so, dass ich es in meine Forms usw. einbinde und dort über die TableAdapters befülle. Sowohl über den Designer, als auch manchmal händisch. Nun habe ich aber auch diverse Helferlein-Funktionen, die auf das DataSet zugreifen und mir gewisse Werte aus den Daten berechnen. Da ich diese Funktionen für verschiedene Forms, Subs usw. benötige, habe ich sie in ein Modul gepackt. Auch bei diesen Funktionen bastel ich mir bisher eine Instanz meines Datasets und befülle es innerhalb der Funktionen. Etwa in dieser Art:

    VB.NET-Quellcode

    1. Dim ds As dsFinanzKnecht = New dsFinanzKnecht
    2. Dim ta As dsFinanzKnechtTableAdapters.BuchungTableAdapter = New dsFinanzKnechtTableAdapters.BuchungTableAdapter
    3. Dim td As dsFinanzKnechtTableAdapters.OrderDauerhaftTableAdapter = New dsFinanzKnechtTableAdapters.OrderDauerhaftTableAdapter
    4. Dim te As dsFinanzKnechtTableAdapters.OrderEinmaligTableAdapter = New dsFinanzKnechtTableAdapters.OrderEinmaligTableAdapter
    5. ta.Fill(ds.Buchung)
    6. td.Fill(ds.OrderDauerhaft)
    7. te.Fill(ds.OrderEinmalig)

    Soweit, so grün. Aber nu werden diese Funktionen z.T. über Schleifen mehrere Dutzend Male hintereinander aufgerufen. Und jedes Mal ziehen die TableAdapter die Daten ins DataSet. Ist perfomancemäßig natürlich übler Schwachsinn und funzt so träge, dasses zum Heulen ist.

    Also überleg ich, ob ich das DataSet irgendwie inner Startprozedur einmalig befülle und dann gobal allen Nutzungen des Progs zur Verfügung stelle. Bei Datenänderungen muss so ein globales DataSet natürlich updatebar sein. Das würde ich in den zuständigen Bearbeitungs-Forms realisieren, wo auch die Validierung stattfindet, so dass an allen anderen Stellen sichergestellt sein sollte, dass das globale DataSet konsistente Daten enthält, die sich auch nicht in irgendwelchen Edit-Modi befinden.

    Ich arbeite bisher nicht in VB mit globalen Objekten (jedenfalls nicht bewusst) und bin mir nicht sicher, wo und wie ich das ansiedeln sollte. In meiner frmMain_load? Kann ich da ein Dataset als Public deklarieren? Bitte seid mir nicht böse, wenn ich hier frage und das jetzt net einfach ausprobiere, ich will mir mein Projekt nicht schreddern. Hat jemand einen Tip, wie ich da vorgehen kann? Gerne auch SuFu- oder sonstiger Verweis. Hab bis itzo nichts Passendes gefunden.

    Danke
    Marsianer
    Ich code nur 'just for fun'! Damit kann ich jeden Mist entschuldigen, den mein Interpreter verdauen muss :D

    Hmmm,

    wenn ich das richtig verstehe, könnte ich mein gefülltes(!) DataSet in eine statische Klasse verpacken und meine Funktionen da als shared dranhängen, ja?

    Danke übrigens für den Link, von MS-Press gibt es übrigens auch die 2008er-Version kostenlos: Entwicklerbuch 2008 :)

    Danke für den Hinweis :)
    Ich code nur 'just for fun'! Damit kann ich jeden Mist entschuldigen, den mein Interpreter verdauen muss :D

    Marsianer schrieb:

    Auch bei diesen Funktionen bastel ich mir bisher eine Instanz meines Datasets und befülle es innerhalb der Funktionen. ...Und jedes Mal ziehen die TableAdapter die Daten ins DataSet. Ist perfomancemäßig natürlich übler Schwachsinn und funzt so träge, dasses zum Heulen ist.
    Wohl wahr - dassis absolut pervers.
    Für Datenbanken gilt absolutes Redundanz-Verbot! Ein Datensatz darf sich nur an einer Stelle im Programm befinden, und auf keinen Fall darf derselbe Datensatz ein zweites Mal geladen werden. Der Performance-Overkill ist noch das kleinste Problem, etwa im Vergleich zur Frage, welcher der beiden Datensätze denn nun abgespeichert werden soll, wenn einer von ihnen oder beide auf verschiedene Weise an verschiedenen Orten geändert wurden.

    Also selbstredend muß ein globales Dataset her.
    In DBExtensions ist das ja sehr listenreich gelöst:
    Jedes Form registriert sein lokales Dataset. Im Code der Registrierung wird nun das Dataset weggeschmissen und durch die globale Instanz ersetzt, und alle BindingSources werden umgestöpselt auf das neue. Auf diese Weise liegt in jedem Form dasselbe Dataset vor, und ist also hinterrücks global geworden, ohne dass der Programmierer das ühaupt merkt.
    Wenn du nun noch besondere dataset-bezogene Methoden in iwelchen Modulen rumfahren hast, so ist das auch kein Problem, denn diese Methoden werden ja zwingend von ieinem dieser Forms aus aufgerufen, oder täusche ich mich?
    Und da kann das Form dann auch sein Dataset übergeben und alle sind glücklich.
    Noch glücklicher sind alle, wenn du deine Spezialmethoden vlt. gar als Extension-Methods ausführst, und noch noch glücklicher sind alle, wenn du deine Methoden, die das Dataset betreffen, dann auch tatsächlich in die Partiale Klasse des Datasets reinpackst - dann sinds nämlich ganz reguläre Objekt-Methoden des Datasets - wie OOP halt gedacht ist :D.

    ErfinderDesRades schrieb:

    Für Datenbanken gilt absolutes Redundanz-Verbot! Ein Datensatz darf sich nur an einer Stelle im Programm befinden, und auf keinen Fall darf derselbe Datensatz ein zweites Mal geladen werden

    Nunja, dem Redundanzverbot bin ich bisher entgangen, indem meine Forms alle als Dialog aufgerufen werden. Dadurch schwirrt immer nur eine Version des DataSet rum. Löst zwar net das Performance-Problem, aber iwie muss man sich ja als Hobby-Progger zu helfen wissen :whistling:

    ErfinderDesRades schrieb:

    Wenn du nun noch besondere dataset-bezogene Methoden in iwelchen Modulen rumfahren hast, so ist das auch kein Problem, denn diese Methoden werden ja zwingend von ieinem dieser Forms aus aufgerufen, oder täusche ich mich?
    Leider nicht. Die Methoden werden auch von anderen Methoden des Moduls benutzt.


    ErfinderDesRades schrieb:

    Noch glücklicher sind alle, wenn du deine Spezialmethoden vlt. gar als Extension-Methods ausführst, und noch noch glücklicher sind alle, wenn du deine Methoden, die das Dataset betreffen, dann auch tatsächlich in die Partiale Klasse des Datasets reinpackst - dann sinds nämlich ganz reguläre Objekt-Methoden des Datasets - wie OOP halt gedacht ist :D.
    Dasissneidee 8-) . Nu bin ich aufgrund meiner rudimentären Kenntnisse schonmal an deinen Extensions gescheitert. Da ich zwischendurch ein bisserl dazugelernt habe, wärs vielleicht mal anner Zeit, einen neuen Versuch zu starten.

    FloFuchs schrieb:

    Hier kannste nachlesen, warum lieber das 2005er
    Oh, das wusste ich net :thumbup:
    Ich code nur 'just for fun'! Damit kann ich jeden Mist entschuldigen, den mein Interpreter verdauen muss :D

    Mach mal 'nen Doppelklick auf die Kopfzeile einer Tabelle Deines typisierten Datasets innerhalb des Dataset-Designers. Dann hast Du bereits den Rumpf Deiner Erweiterung, und kannst nach Herzenslust Funktionen hinzufügen.

    Ich habe mal ein bisserl weitergegoogelt und bin auf folgenden Tipp gestoßen:
    DataSet im Hauptformular einbauen und füllen.
    Da alle anderen Forms vom Hauptformular aus aufgerufen werden: In den Sub-Forms eine Dataset-Property erstellen und dieser Property das gefüllte DataSet des Hauptformulars übergeben. Den Setter der Datasetproperty dazu benutzen, um die Datenbindung der Controls auf die Membervariable der Property umzustöpseln. Wenn ich dann noch meine Funktionen dem DataSet in einer PartialClass dranbamsel...

    ... was haltet ihr davon? Wäre das ein gangbarer Weg für ein "globales" Dataset? (Ja ich weiß lieber EdR, deine Extensions können das vermutlich viel besser, aber ich möchte sehen, ob ich auch eine eigene Lösung - zumindest theoretisch - hinbekäme ;) )
    Ich code nur 'just for fun'! Damit kann ich jeden Mist entschuldigen, den mein Interpreter verdauen muss :D

    Das ist genau der Ansatz, aus dem die DB-Extensions sich entwickelt haben. Ich hab mir halt einen abgebrochen, mittels Reflection eine allgemein verwendbare Methode zum umstöpseln der Datasetse zu schreiben, aber prinzipiell machen die Extensions genau das, was du beschreibst.

    Es gibt übrigens noch einen anneren Weg, die Umstöpselung allgemeingültiger zu machen:
    Du kannst eine MainBindingSource auf jedes Form tun, und die ans lokale Dataset anschließen. Anschließend kannst du im Designer alle Bindings über diese MainBindingSource laufen lassen - nicht über das (lokale) Dataset.
    Zum Umstöpseln brauchst du dann nur eine einzige BindingSource umzustöpseln, und damit ist alles, was weiter daran hängt, ja mit umgestöpselt.

    Naja - Ansichtssache, was günstiger ist. Das mit der MainBindingSource ist bischen umständlicher im Designer, weil das nicht so ganzngar mittm Datenfenster harmonisiert, aber dafür ist der Umstöpsel-Code der allereinfachste (nein - nur der zweit-einfachste;)).

Facebook
Telefonspende