Allgemeine Codefragen



  • Ich habe gerade mit einem kleineren Projekt angefangen und stosse nun auf ein paar Fragen, wie man Code relativ uebersichtlich schreibt.
    Das Projekt beinhaltet einige Forms (WinForms). Zu Beginn wird eine Art Hauptmenue angezeigt, bei der ein Nutzer auswaehlen kann, zu welcher
    Form er gelangen moechte.
    Nun habe ich aber zwei Forms, die nahezu die selben Daten bereitstellen. Auf einer Form werden nur ein paar Spalten weniger angezeigt und
    es kann nichts veraendert werden.
    Wie gehe ich in diesem Fall am besten vor?
    Variante A
    Ich erstelle zwei Forms mit nahezu dem identischen Code, also quasi alles redundant

    Variante B
    Im Hauptmenu werden ueber beide Buttonclicks die selbe Form aufgerufen und ich steuere die Felder dann entsprechend in der zugeoerigen Datei der
    Form
    ==> Vermutlich Variante B, oder?

    Und als weiteres Problem stelle ich mir die Frage, wie Code, der sehr oft an verschiedenen stellen verwendet werden muss nur einmal geschrieben
    werden soll?
    Schreibe ich eine solche Funktion in die entsprechende Klasse und rufe es dann von dort aus?



  • Workshop schrieb:

    Nun habe ich aber zwei Forms, die nahezu die selben Daten bereitstellen. Auf einer Form werden nur ein paar Spalten weniger angezeigt und
    es kann nichts veraendert werden.
    Wie gehe ich in diesem Fall am besten vor?
    Variante A
    Ich erstelle zwei Forms mit nahezu dem identischen Code, also quasi alles redundant

    Variante B
    Im Hauptmenu werden ueber beide Buttonclicks die selbe Form aufgerufen und ich steuere die Felder dann entsprechend in der zugeoerigen Datei der
    Form
    ==> Vermutlich Variante B, oder?

    Variante B hat das Problem das umso unterschiedlicher die beiden Forms aussehen, desto mehr potentiell unnötigen Code zum Ein-/Ausblenden brauchst du. Damit werden zukünftige Erweiterungen erschwert. Das Risiko kann man bewusst hinnehmen wenn man sich ganz sicher ist das es nicht passiert oder sich in Grenzen hält. Grundsätzlich würde ich sowas aber nicht machen, weil sich in der Praxis immer irgendwas ändert.

    Auf Anhieb würde ich eine Variante C versuchen: Man erstellt zwei verschiedene Forms wie in Variante A, packt aber die Darstellung der Daten in ein separates Panel, Widget o.ä. was sich einfach in beide Forms einsetzen lässt.

    Workshop schrieb:

    Und als weiteres Problem stelle ich mir die Frage, wie Code, der sehr oft an verschiedenen stellen verwendet werden muss nur einmal geschrieben
    werden soll?
    Schreibe ich eine solche Funktion in die entsprechende Klasse und rufe es dann von dort aus?

    Grundsätzlich ja. Man muss sich dabei aber auch Gedanken darüber machen wie man das Ganze strukturiert. Welche Sachen gehören zusammen in eine Klasse, welche Klassen gehören thematisch/funktionell zusammen etc. Bei GUI Anwendungen wird als Rahmen häufig ein MVC, MVVM, o.ä. Ansatz verwendet um Daten, Logik und Darstellung voneinander zu trennen. Aber selbst darin gibt es noch viele Details.



  • Dann bin ich für Variante D. Es wird _ein_ einziges Form erstellt. Wenn es tatsächlich nur um Anzeige geht, würde ich anschließend das Model per DI ins Form übergeben und die Daten per DataBinding binden sowie auf Basis des "View"-Model die Datenausgabe erfolgen lassen.

    Das hat aus meiner Sicht den großen Vorteil, dass wenn ein drittes Formular mit wieder fast identisch den gleichen Daten benötigt wird einfach ein neues "View"-Model eingespeist werden kann.

    Gibt noch mehr Möglichkeiten. - Aber das wäre in etwa der Weg den ich wählen würde.



  • WinForms + ViewModel = viel zu Fuss programmieren. Oder hab ich da 'was verpasst?



  • Ich meinte ja auch kein komplettes ViewModel sondern sowas in der Art.

    Im allgemeinen gibt es aber auch schon MVVM Frameworks für Windows Forms. So viel wäre dann auch nicht selbst zu erkämpfen. Man muss dann halt nur darauf achten, dass es eben doch Unterschiede zwischen Win Forms nd WPF gibt.

    Was ich meinte war aber eher ganz grob, eine Modelklasse reinzureichen, die die Daten- und Datenstruktur hält, die an die Oberfläche zu binden sind. Bei einem DataGridView liese sich sowas zum Beispiel relativ einfach Lösen mit einer DataTable im Hintergrund, die je nach Model halt mehr / weniger Spalten hat.



  • Danek für die Anregungen! Vielleicht werde ich mal versuchen, dass ich variante D umsetzen kann 🙂

    inflames2k schrieb:

    Bei einem DataGridView liese sich sowas zum Beispiel relativ einfach Lösen mit einer DataTable im Hintergrund, die je nach Model halt mehr / weniger Spalten hat.

    Ich verwende oft eine DataTable, die dann die Daten einer Klasse enthält. Somit habe ich immer alle Eigenschaften einer Klasse im DataGridView ... wie kann ich es dann umsetzen, dass ich mehr/weniger Spalten habe?

    Bisher löse ich dies immer so - teilweise sehr viel Code, je nachdem was angezeigt werden soll:

    dataGridView1.Columns["columnname"].Visible = false;
    

    Wenn dann mal etwa 20 Spalten nicht angezeigt werden sollen, kommt dann einiges zusammen. Gibt es dafür dann eine elegantere Lösung?



  • Bei Abruf der Daten schon entscheiden, welche Spalten du brauchst sollte dabei helfen. Ich würde die DataTable schon vor dem Anhängen an das DataGridView manipulieren. Entweder direkt bei der Datenabfrage oder aber in den Business-Logik.

    Am einfachsten wäre da wohl eine Konfigurationsdatei die definiert bei welchem Dialog welche Spalte benötigt wird. - Spalten die dann nicht in der Liste für den Dialog vorkommen würde ich einfach per Schleife ausblenden / aus der DataTable entfernen.


Log in to reply