Erkenntnis MVC? neuer Ansatz?

Hallo Community

Ich war schon immer ein Fan vom MVC-Ansatz, und habe diesen auch immer Umgesetzt, indem ich SQL Abfragen immer von der Darstellung trennte.
Nun habe ich aber einen neuen Ansatz, und zwar, dass sich nicht einmal mehr die View um ihre eigenen Inhalte kümmert. Habe dazu eine kleine App geschrieben, um zu testen. (Im Anhang)

MVC.Controlling.dll (Windows Forms Project)*AppControl.cs (Ruft das Hauptform und registriert sämtliche Events)

MVC.Application*Form1.cs (Enthält einen Button und ein Label, macht selbst nichts beim ButtonClick)

MVC.Data*Person.cs (Einfach eine Klasse mit zwei Attributen um zu testen)

Wie findet ihr diesen Ansatz? Arbeitet ihr so? Was ist eure allgemeine Meinung zu diesem Thema?

Liebe Grüsse
Michael

Hallo michaelschuler,

die Trennung der SQL Abfragen hat m.E. nichts mit MVC zu tun, sondern mit der Trennung von Modell und Datenhaltung und liegt in meinen Augen daher eine Ebene unter MVC.

In deinem Ansatz hast du ein Modellklasse Person. Das ist gut. Was mit nicht klar ist, warum z.B. der Buttonclick außerhalb der Form behandelt wird? Das würde ich nicht tun. Du musst dadurch nur unnötig viel Internes des Forms nach außen reichen, z.B. LabelText.

Siehe dazu auch meinen Beitrag die Trennung von M und VC in Trennung von Awendungslogik und Optik

herbivore

Hi michaelschuler,

was du da beschreibst, ist in etwa der normale, saubere MVC-Ansatz.

Es gibt Views,

• "dumme" Windows-Controls/Forms, in die der Benutzer was eingibt.

Model-Klassen,

• Datenhaltung und Anwendungslogik.

Und es gibt Controller-Klassen

• die eigentliche Anwendung (aber hat enthält keine/wenig Programmlogik).
• Sie verwendet die Model-Klassen und Views.
• Sie verknüpfen und initialisieren das Ganze.

Beispiel - Benutzer einloggen.

// GUI-Komponente, kennt nur sich selbst.
public class LoginDialog : Form {
   public string User { get; set; }
   public string Password { get; set; }
   public string LoginErrorMsg { get; set; }
}

// Model-Klasse, kennt nur sich selbst.
public class UserManager {
   public bool Login(string user, string password);
   public string LoginErrorMsg { get; }
}

// Controller (Anwendung), verwendet LoginDialog und UserManager.
public class App {

   private bool loggedIn = false;
   private LoginDialog loginDialog;
   private UserManager userManager;

   public static void Main() {
      new App().Login();
   }

   public App() {

      loginDialog = new LoginDialog();
      loginDialog.Closing += new CancelEventHandler(HandleClosing);

      userManager = new UserManager();
   }

   public void Login() {
      loginDialog.ShowDialog();
      Console.WriteLine("Logged In: {0}", loggedIn);
   }

   private void HandleClosing(object sender, CancelEventArgs e) {
      e.Cancel = !DoLogin();
   }

   private bool DoLogin() {

      // (Edit: hab ich aus dem HandleClosing rausgezogen. 
      // Ist hier besser aufgehoben).
      if(loginDialog.DialogResult != DialogResult.Ok) {
         loggedIn = false
         return true; // e.Cancel = false;
      }

      loggedIn = userManager.Login(loginDialog.User, loginDialog.Password);
      if(!loggedIn) {
          // Kann man auch über ein "bound property" realisieren.
          userDialog.LoginErrorMsg = userManager.LoginErrorMsg;
      }
      return loggedIn;
   }

}

(Hier werden wahrscheinlich Syntaxfehler drin sein, hab's nur schnell geschrieben. Geht nur ums Prinzip)

Im Anhang das Ganze nochmal als Diagramm. Gestrichelte Linien stellen Ereignisse da. Die durchgezogenen Linien sind die Assoziationen/Abhängigkeiten.

Gruss
Pulpapex

Original von Pulpapex
was du da beschreibst, ist in etwa der normale, saubere MVC-Ansatz.

Ja genau, so habe ich MVC auch verstanden. Doch muss ich gestehen, es bis anhin immer so wie herbivore gemacht zu haben. Also dass View auch die rudimentärsten Programmlogiken enthielt oder dass die Form die Daten von einer Managerklasse holt und in die ListView einfüllt etc... strikte nach MVC ist das ja verboten, oder siehst du das anders?

Danke für eure Antworten 😉

LG Michael

Hallo zusammen,

scheinbar gibt es im Netz wirklich unterschiedliche Sichtweisen, was MVC bedeutet. So schreibt die deutsche Wikipedia, was Pulpapex beschreibt und die englische Wikipedia schreibt, was ich meine. Ich habe auch ein Bild gefunden, dass meine Vorstellung von MVC visualisert:

Ich finde meine Vorstellung passt besser zu Windows-Forms.

herbivore

Microsoft benent diese beiden Varianten als "passiv" und "aktiv".

http://msdn.microsoft.com/library/en-us/dnpatterns/html/DesMVC.asp?frame=true

Bei Forms-Anwendungen spielt der Controller nur eine untergeordnete Rolle. Wird der Controller komplett mit den Views verschmolzen, nennt man das Document-View-Pattern.

Mit der deutschen Wikipedia-Version von MVC stimme ich überhaupt nicht überein. Dort implementiert der Controller die Anwendungslogik. Das Model hält nur die Daten.

Diese Trennung von Logik und Daten macht keinen Sinn. Ich hatte das schon mal hier irgendwo erläutert. Was nutzt einem die Logik im Controller? Der Controller kennt die View! Wenn man eine schlanke Kommandozeilen-Version für sein GUI-Programm anbieten möchte, geht das nicht. Man muss immer die fette GUI mit ausliefern, weil die Anwendungslogik von ihr abhängt.

Mein Beispiel sieht ganz anders aus. Dort stellt der Controller nur Glue-Code ohne eigene Logik da. Er konfiguriert Model und View, reagiert auf deren Ereignisse und delegiert sie als Aktionen weiter (Closing-Event -> Login -> userManager.Login -> e.Cancel).

Möchte man Model oder View ersetzen, muss man auch immer den Controller mit ausgetauschen. Also die App.exe muss neu geschrieben werden. Ziel ist es deshalb den Code im Controller möglichst klein und einfach zu halten, damit der Austausch nicht zu viel Aufwand macht.

herbivore, in deinem Diagamm ist nicht zu erkennen, dass die Benutzer-Interaktionen eigentlich über Ereignisse der View mitgeteilt werden: okButton.Click - der Benutzer hat den Schalter gedrückt. Auch sieht es so aus, als würde das Model die View kennen. Das liegt aber nur an der Darstellung, die sehr von der Programmierersicht abstrahiert. Eigentlich soll dein und mein Diagramm genau das selbe darstellen. Der Controller reagiert auf Ereignisse und bedient das Model. Bei mir bedient er noch die View, z.B. öffnet er Dialoge oder schaltet Sichten um. Model-Aktualisierungen kommen auch bei mir, wenn möglich direkt ohne Umweg über den Controller zur View, per Event oder bound Properties.

Gruss
Pulpapex