Heyho,
also ich würde mir wohl als Erstes ein Hauptmodul basteln. Darein würden dann immer die benötigten Oberflächen geladen bzw die Anträge in deinem Fall (Factory-Pattern). Dabei würde ich auch wirklich lieber mehr Klassen anlegen, da soetwas meiner Meinung viel leichter anpassbar ist. Wer weiß, was später nochmal dazu kommt? Zusätzlich würde ich jenachdem noch ein MVC-Pattern (Model-View-Control) für die Daten benutzen.
Das würde dann z.b. so ablaufen:
1. Anwender wählt eine Antragsart aus (ein View bzw. eine Oberfläche wird von der Factory erstellt und einem Model bzw. Datenspeicher zugewiesen)
2. Änderungen an der View wurden vorgenommen, View teilt dem Controller mit das Änderungen vorgenommen wurden, Controller updatet das Model und teilt allen anderen Views bzw. Oberflächen mit (z.b. wenn man mehrere Formulare auf einmal hat die miteinander zusammenhängen und ähnliche Daten besitzen) das sie sich aktualisieren sollen.
3. View wird nicht mehr gebraucht und geschlossen und von dem Model getrennt.
Zwar ein großer Aufwand, jedoch sehr leicht anpassbar und die Daten sind von den Oberflächen getrennt.
Dies habe ich z.b. bei einem dynamischen Suchdialog für eine Datenbank benutzt. Dort gab es ein Hauptformular, wo man mehrere Suchfilter anlegen konnte (verschiedene Views), diese wurden immer mit einem Model gekoppelt (welche den
SQL-Teil beinhalten, also Tabellenname und Feldname zum Beispiel). Am Ende wurde dann anhand aller Daten der Models ein
SQL-Befehl erzeugt.
Jetzt muss ich nur noch die Models austauschen (was jeweils eine Anpassung von drei Zeilen ist) und kann den Rest weiterbenutzen. Die Views sind ja nur die Oberflächen, wie z.b. eine simple Textsuche.
So das wars erstmal von mir...falls etwas unverständlich war einfach sagen
Alaitoc
Edit: Natürlich ist dabei immer die Frage ob sich der Aufwand wirklich lohnt bzw. man die Zeit dazu hat. Ich würde dir ja gern mal das Projekt zeigen, aber war ein Firmenprojekt. Vll. kann ich zumindest später mal ne grobe Klassenansicht zeigen.