Laden...

MVC Umsetzungsproblem - Kommunikation(sbeziehung) zwischen V und C

Erstellt von Michael65589 vor 14 Jahren Letzter Beitrag vor 14 Jahren 3.523 Views
M
Michael65589 Themenstarter:in
32 Beiträge seit 2009
vor 14 Jahren
MVC Umsetzungsproblem - Kommunikation(sbeziehung) zwischen V und C

Hallo zusammen,

ich habe ein Verständnisproblem bzw. weiß nicht wie ich es umsetzten soll. Und zwar habe ich eine Form mit z.B. einem toolStripStatusLabel.
Dann habe ich ein zweiten File generiert "control.cs". Dort soll eine Verarbeitung stattfinden und der Fortschritt an das StatusLabel in Form1 gemeldet werden.

Ich dachte ich generiere ein Event in Form1 und kann dann von Control darauf zu greifen. Leider steht mir das Event in Control nicht zur Verfügung.

Wenn ich Form1. tippe, kommt kein Vorschlag, der auf mein Event deutet.

Wie macht man das?

Hintergrund ist folgender: Ich möchte die Form1 als View benutzen und meine Control.cs als Control und oder Model. Halt nach dem MVC Schema.

Kann mir einer helfen?

4.931 Beiträge seit 2008
vor 14 Jahren

Das Event solltest du in der "Control.cs" definieren und vom Formular abonnieren (also umgekehrt zu deiner bisherigen Vorgehensweise).
Und du mußt natürlich eine Objekt-Instanz benutzen, um auf das Event zuzugreifen (außer du hättest ein statisches Event erzeugt - aber das ist in deinm Fall nicht angebracht).


// MyControl.cs
class MyControl
{
  public event MyEventHandler MyEvent;
}

// MyForm.cs
class MyForm
{
   MyForm()
   {
       //MyControl myControl; // <- MyControl per Designer auf Form gesetzt

       myControl.MyEvent += myControl_MyEvent;
   }
}

M
Michael65589 Themenstarter:in
32 Beiträge seit 2009
vor 14 Jahren

Danke Th69 das hat mir weitergeholfen.

Ich habe noch eine Frage. Die Form1 dient ja bei mir nur zum Anzeigen von Informationen und Entgegennehmen von Aktionen. Was wie gemacht wird soll dann in der Control.cs entschieden werden.

Legt man dann in der Regel in der Control.cs für alles Mögliche Events an, die die Form dann abonniert?

Also toolStripStatus zurücksetzen, toolStripStatus erhöhen usw.

Die Form reagiert dann quasi nur noch auf Events.

Ist das prinzipiell richtig so?

R
69 Beiträge seit 2009
vor 14 Jahren

Hi,

wir wollen unsere Anwendungen nach dem MVVM-Pattern ausrichten...Das soll nach diversen Internet-Aussagen fortschrittlicher als das MVC-Pattern sein. Habe Dir mal ein Beispiel angehängt, vielleicht hilft Dir das auch ein bisschen weiter...

Mfg Ron

[EDIT=herbivore]Projekt entfernt[/EDIT]

4.931 Beiträge seit 2008
vor 14 Jahren

Hallo Michael,

ja, das Control muß völlig autark arbeiten und bietet über die Events eine Schnittstelle nach außen an (egal ob es dann von einer Form oder einem UserControl oder ... benutzt wird).

Und Ronny,
also MVVM und WinForms passen m.E. nicht wirklich zueinander - ist ja extra für WPF erfunden worden (wo es eine strikte Trennung zwischen Controls und Layout (Darstellung) gibt - es also wirklich verschiedene Views gibt.
Dein Projekt hat m.E. viele zu viele Code-Doppelungen drin (die Logik-Klassen sind nochmal komplett in den Modelklassen enthalten etc.).
Trennung von Logik und View geht in WinForms viel einfacher...

6.862 Beiträge seit 2003
vor 14 Jahren

Hallo,

... ist ja extra für WPF erfunden worden ...

Naja, bei WPF hats den Namen MVVM bekommen, aber eigentlich ist es ja MVP und das gabs vom Konzept schon vor WPF.

Aber ja, MVVM und Windows Forms passt nicht wirklich gut zusammen.

@Ronny75
Ihr habt prinzipiell schön die Teile getrennt, aber wie TH69 schon gesagt hat, sind dort viele Codedopplungen und was mit das schlimmste ist - ihr habt euer ViewModel als Member in der View. Damit ist doch jede Trennung von GUI und Model dahin. Genauso habt ihr Eventhandler in euer Form die direkt Methoden aus dem ViewModel aufrufen. Da ist wieder keine Trennung da.

Nicht das eure Auftrennung prinzipiell schlecht ist, aber es ist halt kein MVVM 😃

Baka wa shinanakya naoranai.

Mein XING Profil.

R
69 Beiträge seit 2009
vor 14 Jahren

Hi,

also da handelt es sich um ein kleines Mißverständnis, da habe ich mich wohl nicht richtig ausgedrückt. Das Beispielprojekt ist keines von uns. Ein Kollege hat es wohl von Dot.Net Pro (oder war es die andere Zeitschrift?) heruntergeladen.

In Zukunft werde ich die Quelle wohl besser angeben. Sorry.

Mfg

Ron

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo ronny75,

noch besser ist es, Projekte aus anderer Quelle gar nicht hochzuladen. Ich habe das Projekt sicherheitshalber entfernt, bis geklärt ist, ob du überhaupt das Recht hattest, es hier zu veröffentlichen. Das ist bei Projekten aus Zeitschriften nämlich selten der Fall.

Auch wenn ihr relativ konkrete Fragen zu Windows-Forms-Programmierung gestellt habt, ist es letztlich doch eine Designfrage bzw. eine Frage zu Entwurfsmustern. Deshalb habe ich den Thread nach "Rund um die Programmierung" verschoben.

Meine Empfehlung ist ohnehin, zwar das Modell strikt vom GUI zu trennen, aber nicht das View vom Controller. Das macht bei normalen Windows-Forms-Anwendungen keinen Sinn, sondern schafft nur unnötige Redundanzen, ohne dass man etwas dadurch gewinnt.

Wenn ihr es doch trennen wollt, dann sollte der Controller das View kennen, aber nicht umgekehrt. Events braucht ihr also nur, wenn das View dem Controller etwas mitteilen will. Wenn der Controller will, dass das View etwas tut, kann er einfach eine entsprechenden Methode des Views aufrufen. Dafür braucht man keine Events und sollte keine Events verwenden.

herbivore

F
10.010 Beiträge seit 2004
vor 14 Jahren

Komisch, MS hat in CAB/SCSF das genau anders herum implementiert.

Der View kennt dort direkt den Controller(Presenter), der kennt aber nur ein Interface vom View.

49.485 Beiträge seit 2005
vor 14 Jahren

Hallo FZelle,

gerade von MVC gibt es ja unzählige sehr unterschiedliche Varianten.

herbivore

F
10.010 Beiträge seit 2004
vor 14 Jahren

wie war!

C
401 Beiträge seit 2007
vor 14 Jahren

Also die vorgehensweise, die ich am häufigsten gesehen habe (z.B. Qt, iPhone SDK...) ist die, dass der Controller eine Referenz auf die View hat und über öffentliche Methoden/Properties die View verändern kann. Ist imho auch der beste Weg, da man da nicht in die Versuchung kommt Logik in die Forms zu packen. Auch das Abonnieren eines Events ist imho etwas, was nicht in die View gehört, da dort ja wieder Logik ausgeführt wird.

M
Michael65589 Themenstarter:in
32 Beiträge seit 2009
vor 14 Jahren

Und wie übergebe ich die Referenz?

So?

//Form1.cs:
Control MyControl = new Control(Form1);

//Control.cs:
public class Control
{
  Form ViewF;
  public Control (Form ViewForm)
  {
     ViewF = ViewForm;
  }
}

Dann hab ich von Control aus Zugriff auf alle Elemente von Form1?

C
401 Beiträge seit 2007
vor 14 Jahren

Neee.... dann haste ja ne Instanz vom Controller in der Form und andersum... Du könntest z.B. die FOrm im Controller instanziieren und nur über den Controller Zugriff darauf gewähren.

F
10.010 Beiträge seit 2004
vor 14 Jahren

@Corpsegrinder:
Der Controller sollte ein Interface zum View haben, wie soll man ihn sonst Unittesten?

Vielleicht einfach mal SCSF ansehen:

http://www.codeplex.com/smartclient

Ist zwar umfangreich, aber es hilft fürs verständnis.

C
401 Beiträge seit 2007
vor 14 Jahren

Hab ich irgendwo das Gegenteil behauptet? Ich sagte nur, dass man den Controller nicht in der Form instanziieren soll, sondern andersrum.

M
Michael65589 Themenstarter:in
32 Beiträge seit 2009
vor 14 Jahren

Muss ich dazu dann die Main in den Controller packen, oder wie macht man das?

Habt Ihr vielleicht ein kleines Beispiel?

Gucke mir aber auch das SCSF an.

C
401 Beiträge seit 2007
vor 14 Jahren

Nein, du hast weiterhin deine normale Main(), aber dort erstellst du einen MainFormController und rufst dann Application.Run(controller.View) auf.

edit:

gerade noch nen guten Link gefunden: http://www.programgood.net/2009/07/17/SimpleMVCInWinForms.aspx

F
10.010 Beiträge seit 2004
vor 14 Jahren

@Corpsegrinder :
Ist nicht wirklich richtig.
Wie herbivore schon sagte, es gibt haufenweise implementierungen von MVC/MVP.
Und es ist dabei nur wichtig, das getrennt wird, nicht genau wie.

Bei SCSF ( ist vom Architekturteam von MS ) wird der Presenter/Controller in der Form
angelegt, und bekommt das Interface der Form dann als Property injected.

C
401 Beiträge seit 2007
vor 14 Jahren

Naja.. wie schon gesagt... das ist meine Meinung. Ich frage mich halt einfach, warum die Form den Controller kennen soll? Es reicht vollkommen aus, wenn der Controller die Form kennt. In Frameworks, wo die Form in einem XML Format gespeichert wird (z.B. Qt) geht es auch nicht anders (außer man schreibt die Form von Hand als Klasse).

F
10.010 Beiträge seit 2004
vor 14 Jahren

Der Controller muss definitiv die Form kennen ( wenn auch über Interface ) das ist richtig.

Wenn man aber wie z.b. SCSF ViewCentered arbeitet, also die Views erzeugt,
dann müssen die zwangsweise auch den Presenter/Controler kennen.

In den von Dir genannten ( z.b. auch bei WPF ) hat sich dann eher etwas wie MVVM durchgesetzt.

C
401 Beiträge seit 2007
vor 14 Jahren

In den von Dir genannten ( z.b. auch bei WPF ) hat sich dann eher etwas wie MVVM durchgesetzt.

Also WPF habe ich zwar nicht genannt, aber in den von mir genannten ist es kein MVVM (MVVM wurde von Microsoft festgelegt und ist auch fast ausschlielich dort zu finden), sondern MVC und zwar hat es sich da nicht durchgesetzt, sondern ist das Standardverfahren, welches die Entwickler der SDKs vorschlagen. Sowohl der QtCreator, als auch XCode bieten dir mit dem Interface Builder keine andere Möglichkeit. Ist jetzt aber auch egal, da dass langsam ausartet.