Datenübergabe

Hallo Forum

Mir fehlt bei folgendem Problem eine Idee zu einsteigen.

Ich möchte folgendes machen:
Ich habe eine MainForm mit einem DataGrid und eine zweite Form mit Textfeldern usw.:
Ich möchte jetzt mittels einer Klasse Daten in das DataGrid schreiben aber von
der zweiten Form aus, also ich gebe in Form2 Daten ein und diese sollten im
DataGrid angezeigt werden, dieses ist jedoch in Form1(MainForm).
Das ganze funktioniert zwar mit einem Dialogfeld(also mit DialogResult).
Das möchte ich aber nicht, mann soll z.b.: in Form2 Daten eingeben können, wenn
ich dann z.b.: auf OK drücke sollen die Daten in das DataGrid geschrieben werden,
Form2 soll aber nicht geschlossen werden sondern es soll die Möglichkeit für einen zweiten Eintrag bestehen usw. bis ich Form2 schliesse.

Ich hoffe ich habe mein Problem einigermassen erklärt.

Bin für jeden Ansatz dankbar............................

Erzeuge in Form1 einen Delegaten, übergebe ihn an Form2 im Konstruktor und schicke beim "Ok" in Form2 die Daten mittels des Delegaten an Form1.

Das ist der klassische Callback-Ansatz für asynchrone Ergebnisrückmeldung.

Das ist ein Fall für MVC (Model-View-Controller). Du hast folgende Bestandteile:

Model

Eine Klasse, die das DataSet hält und Methoden zum lesen und schreiben der Daten zur verfügung stellt. Außerdem veröffentlicht das Model Ereignisse, die Views über Änderungen informieren.
Wichtig! Das Model darf nicht auf die Views oder den Controller zugreifen. Wenn sich das Model mitteilen will, tut es das über Events.

View

Verschiedene Controls, Forms etc. die einen Verweis auf das Model halten. Eine View konsumiert sozusagen das Model. Über das Model, können Views auf das DataSet zugreifen. Views registrieren auch Ereignisprozeduren für Model Ereignisse. Das ist Sinnvoll, da alle Views mit dem selben Model arbeiten. Wenn z.B. die View Form2 eine neue DataRow in einer Table des DataSets anlegt, feuert das Model ein entsprechendes Event (da der Zugriff auf das DataSet NUR über das Model erfolgt). Dieses Event behandelt die View Form1 und zeichnet das Grid neu.

Controller

Eine Klasse, die das Model und sämtliche Views erzeugt. Der Controller teilt jeder View beim erzeugen das Model zu. In MDI-Anwendungen wird oft das Hauptformular als View und Controller gleichzeitig eingesetzt.

Damit die Views auch vom Controller mit dem Model verbunden werden können, sollte jedes Model die folgende Schnittstelle implementieren:

public interface IView
{
    // Für ModelClass den Namen Deiner Model-Klasse einsetzen
    ModelClass Model
    {set;}
}

Wenn man das MVC-Pattern mal verstanden hat, ist es sehr einfach anzuwenden. Es ist besonders bei komplexeren Benutzeroberflächen nützlich. Außerdem erleichtert es die nachträgliche Erweiterbarkeit einer GUI-Anwendung. In Firmen ändern sich Workflows ständig. Deshalb sind flexible Anwendungen vorteilhaft.

Da das MVC-Pattern ursprünglich von Smalltalk 80 kommt und schon etwas älter ist, finden sich viele unterschiedliche Implementierungen. Bei der Ur-Version hat der Controller sämtliche Tastatureingaben entgegengenommen und ausgewertet (Mäuse waren damals noch nicht so verbreitet). Da man sich bei .NET Programmen nicht mehr selbst um die Behandlung von Tastatur- und Mauseingaben kümmern muss, fällt dieser Part des Controllers weg. Ich sage das alles deshalb an dieser Stelle, weil wir bei uns in der Firma zahlreiche Diskussionen zu diesem Thema hatten.

Patterns sind nur Richtlinien, keine starren Schablonen!

Hi Rainbird,

so in der Art habe ich das MVC-Pattern auch verstanden.

Konkret zum Controller:
Normalerweise registriert der Controller die View für Model-Ereignisse und umgekehrt (oder er verbindet Daten-bindungsfähige Properties). Ansonsten hat er nicht viel zu tun. Er kann sich auch selbst für die Ereignisse registrieren, wenn ein direktes Verbinden von Model und View nicht möglich ist. Der Code im Ereignishandler sollte dann allerdings so kurz wie möglich sein. Auf keinen Fall darf der Contoller selbst auf Ereignisse reagieren. Er darf nur sehr wenig Logik enthalten.

Für mich ist der Controller nur notwendiger Glue-Code. Wird die View oder das Model wiederverwendet, muss der Controller in jedem Fall neu geschrieben werden.

In der Wikipedia ist das, finde ich, falsch beschrieben. Dort enthält der Controller alle Anwendungslogik. Das Model enthält nur die Daten, aber nicht keine Operationen auf diesen, wie es eigentlich sein sollte.

Wikipedia: Model View Controller

Controller

Die Steuerungsschicht realisiert die eigentliche Geschäftsintelligenz und bildet mit Hilfe der anderen Schichten die Prozesse ab. Sie steuert den Ablauf, verarbeitet Daten, entscheidet, welche View aufgerufen wird, etc.

An dieser Stelle driften die Ansichten auseinander. Aber es muss eigentlich falsch sein, ... wenn der Controller die Logik enthält und dazu noch die View kennt, kann die View nicht ohne weiteres ausgetauscht werden. Der Controller kommt ohne die View nicht aus. Das bedeutet, dass alle drei Komponenten eng verbunden sind, was MVC ja gerade verhindern soll.

Also eigentlich müsste der Artikel angepasst werden. Oder gibt es noch andere Sichtweisen?

Gruss
Pulpapex