Wann bzw. Wo sollen Instanzen von Klassen innerhalb einer Form erstellt werden?

  • VB.NET

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Wann bzw. Wo sollen Instanzen von Klassen innerhalb einer Form erstellt werden?

    Hallo Community,

    meine Frage betrifft das "Wann" und "Wo" ihr eure Instanzen von Klassen/Datenbankanbindungen etc. macht, welche in einer Form verankert sind?

    Ist es sinnvoll diese in der "New" Procedure zu machen oder in der "Load" oder überhaupt eine Methode zu schreiben, welche dann aufgerufen wird?
    Bei meinen Instanzen geht es unter anderem um Klassen, wo z.B. mehrere Datenbankanbindungen hergestellt werden. Das sind Klassen z.B. für Logging, Error und auch der Datenaustausch der GUI

    Derzeit mache ich, wenn ich z.B. eine neue Form mit Datenbankanbindung instanziere, alles in der "New" von der Form. Meine Frage an euch, ist das sinnvoll, macht ihr das auch so? Was wäre der sinnvollere Code? Eigene Methode, welche dann aufgerufen wird?

    Danke euch.

    DataStore-Klasseninstanziierungen mach ich - falls möglich - außerhalb einer Methode, also bei der Variablendeklaration. Sollte dies nicht möglich sein, dann in einer eigenen Methode, welche aber vom Form_Load-EventHandler bzw. Form_Shown-EH aufgerufen wird. Das Auslagern in eine eigene Methode mach ich aber nur deshalb, weil das zu meiner Programmarchitektur gehört, Stichwort IOSP. Den Form-Konstruktor verwende ich selten explizit.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    @GerhardW Ich präferiere zwei Stellen zum Instanziieren von Klassen in Formen.
    Einmal im Konstruktor, dort werden alle Instanzen von Klassen erstellt, die keine oder nur lokale Parameter haebn.
    Bei mir kommt oft der Fall vor, dass ich Initialisierungsroutinen über Interfaces organisiere, die alle äquivalente oder identische Parameter benötigen.
    Dann wird über alle diese implementierten Interfaces die Initialisierung durchgeführt, wenn die erforderlichen Daten / Parameter zur Verfügung stehen.
    Du sprachst das Load-Event an, davon muss ich Dir dringend abraten, denn einige Exceptions werden im Load verschluckt, so dass Du ggf. gar nicht mitbekommst, dass eine Initialisierung fehlgeschlagen ist.
    Also:
    Instanziierung von Klassen im Konstruktor oder einer speziellen Initialisierungs-Routine.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    GerhardW schrieb:

    Ist es sinnvoll diese in der "New" Procedure zu machen oder in der "Load" oder überhaupt eine Methode zu schreiben, welche dann aufgerufen wird?
    Ja.
    Alle drei sinnvoll - such dir was aus.

    GerhardW schrieb:


    Bei meinen Instanzen geht es unter anderem um Klassen, wo z.B. mehrere Datenbankanbindungen hergestellt werden.

    Ausserhalb des Forms ist das typDataset, erweitert (häufig sehr erweitert) mittels partialer Klassen.
    Weil alle Forms müssen an dasselbe Dataset binden.
    Hier findet auch der Db-Zugriff statt, weil die Db soll ja das Dataset befüllen (nicht iwelche Forms), bzw. Änderungen rückschreiben.
    Für den Austausch Dataset<->Db habe ich einiges an Infrastruktur, also das ist nur einmal gecodet und dann in allen Projekten, mit allen Dbs, und allen Tabellen verwendbar.
    Auch fürs DataBinding aller Forms ans selbe Dataset habich Infrastruktur.

    Dann teile ich meine Projekte nicht nur in Forms auf, sondern auch in UserControls - quasi UnterForms im MainForm.

    So weiss ich immer wo was hingehört:
    • Gui-Fachlogik in Ucls und Forms
    • Business-Fachlogik in die Erweiterungen des Datasets
    • Infrastruktur in die Infrastruktur-Dlls.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    ErfinderDesRades schrieb:

    sondern auch in UserControls
    Jou.
    Z.B. Konfigurationsdialog mit TabControl und 10+ Tabulatoren.
    @GerhardW Insbesondere diese implementieren bei mir diverse Interfaces.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    @RodFromGermany @ErfinderDesRades @VaporiZed

    Also bei mir gibt es Klassen, welche eine bestimmte Aufgabe erfüllen. Diese Klassen verbinden sich mit der Datenbank.
    z.B. habe ich für den Datenaustausch mit der Datenbank für jede Tabelle eine DataModel Klasse mit diversen Methoden und Properties. Ebenso gibt es eine Klasse z.B. für das Logging.
    Ich versuche strict die GUI von der Datenbank zu trennen. In der GUI befüllle ich mein Datenmodell und löse dann z.B. die Methode zum Speichern aus. Genau so umgekehrt. Das Datenmodell liest den Datensatz und die GUI macht nur die Anzeige der Felder (Spalten).

    Diese Klassen (DataModel, Logging...) instanziere ich eben in der "New" Procedure beim Erstellen einer Forminstanz. Vielleicht sollte ich für die Instanzierung der Klassen, wo eine DB Anbindung gemacht wird, in eine eigene Procedure geben. Muss mir das einmal überlegen.

    Jedenfall danke ich euch für eure Infos.

    GerhardW schrieb:

    z.B. habe ich für den Datenaustausch mit der Datenbank für jede Tabelle eine DataModel Klasse mit diversen Methoden und Properties.
    puh - da haste dir aber eine Menge Arbeit gemacht.
    Und Änderungsverfolgung ist sicherlich noch nichtmal inbegriffen.

    Man kann sich den ganzen Salat auch in form eines typDatasets aus der Datenbank generieren lassen.
    So erhält man ein enorm leistungsfähiges Datenmodell geschenkt, und kann es auch noch beliebig um allerlei Spezial-Funktionen erweitern.
    Bei Interesse guggemol Dataset->Db
    Das sind gleich mehrere Beispielanwendungen, such dir eine aus, und überleg, wie du das umgesetzt hättest.

    @ErfinderDesRades

    Jo, schau ich mir an. Vielleicht finde ich Anregungen und Ideen.

    Für die Erstellung der DataModel Klassen habe ich ein Tool (Table2Class), welches ich erweitert habe. Der Grundcode wird mir quasi automatisch erstellt und ich füge nur die notwendigen Methoden etc. hinzu.

    Für meine DataModel Klassen habe ich mir eine eigene Logging Klasse geschrieben, welche mir die Änderungen der Werte quasi dokumentiert. Das funktioniert wunderbar.

    bei Änderungsverfolgung kommts nicht drauf an, Änderungen zu dokumentieren, sondern mit typDataset kannst du verschiedenerlei Änderungen (zufügen, edit, löschen) an verschiedenen Datensätzen ausführen, sogar an verschiedenen Tabellen.
    Ohne dass deswegen mit der Db telefoniert werden müsste - die Änderungen bleiben erstmal lokal im typDataset.
    Und mit geeigneter Infrastruktur kann man mit einer einzigen Zeile Code sämtliche Änderungen (und nur die Änderungen, nicht mehr!) an die Db schicken.
    Die verwendeten DataAdapter unterscheiden automatisch den Änderungs-Typ (zufügen, edit, löschen), und setzen den geeigneten Befehl an die Db ab.
    (Und insbesondere erkennen sie, welcher Datensatz garnet geändert wurde, und überspringen diese).

    Und wie gesagt, das muss man nciht neu erfinden, sondern das gibts alles schon seit 15 Jahren für umsonst, und zwar Framework-OnBord.

Facebook
Telefonspende