Nein. Aber der Code in den Eventhandlern sollte übersichtlich bleiben und nicht zu lange werden. Ein handvoll Zeilen aus denen klar hervorgeht was passiert. Klassen eignen sich an sich recht gut die Daten zu kapseln. Ich persönlich arbeite sehr viel Bottom Up.
Ich habe sehr selten verwendet Data Binding. Mein Ansinnen war einfach die reinen Windows Controls zu verwenden.
Einfach Collections aufgebaut oder ein respräsentatives Objekt über einen Dataset gelegt. Das bedingt die Generierung des Data
Access Layers. Aber auch nicht mehr. Man fängt damit Datenfehler sehr bald und man kommt mit einem TQuery Objekt durch. Damit macht das Rumpfrimmeln in den Eventhandlern kaum Sinn. Damit bügelt man so 95% der lästigen unerwarteten Fehler. Das ganze geht noch dazu ganz gut in Funktionen. Wenn man sich viel an Funktionen hält bekommt man relativ sauberen Code. Der hat keine Side Effekts. Ein Funktion weiß an sich vom Form nichts aber auch gar nichts. Prozedurtypen als Parameter sind genausowenig verboten.
Ich kann mir jetzt mal für diese Art von Applikation nicht den wirklichen Nutzen von einem reinen MVC vorstellen. Ich kann mir den Nutzen bei vielen anderen Anwendungsfällen vorstellen, das Wohl.
Kann mir mal jemand bitte erklären, wie dieses viel besungene Trennen von Code und Oberfläche geht? Ist ja schon blöd, wenn man nicht mehr sieht, was der Code ausgerechnet hat (Spass). Sollen die Events jetzt per Rauchzeichen den Code triggern?