Laden...

Ist das akzeptable GUI Trennung?

Erstellt von inflames2k vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.390 Views
inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 13 Jahren
Ist das akzeptable GUI Trennung?

Hallo,

aufgrund eines aktuellen Projektes wollte ich mal einen anderen Anwendungsaufbau nutzen. - Normalerweise hab ich immer direkt in der Form die benötigten Klassen zur Datenbankabfrage etc. instanziert.

Gedacht hatte ich es so, dass ich eine Klasse "MainController" erstelle, und diese die Instanzen für Datenbankabrufe und Programmlogik beinhaltet.
Die Form würde rein über Events mit dem Controller kommunizieren & dieser führt dann die benötigte Programmlogik aus, ist er fertig setzt er die Daten dann in der Form. - Für weitere Forms würde ich dann weitere Controller implementieren.

Im Code würde es etwa so aussehen (nur Beispielcode):


class MainController
{
      private FrmMain _mainForm;
      private DataBaseConnection _dataConnection;
      private List<SomeTypeToVisualize> _someData;

      public event EventHandler ApplicationExitEventHandler;

      public MainController()
      {
               _mainForm = new FrmMain();
               _dataConnection = new DataBaseConnection();
               _mainForm.FormClosed += new EventHandler(MainClosed);
               _mainForm.SomeCommandEvent += new EventHandler(SomeCommand);
               _mainForm.Show();
      }

      private void MainClosed(object sender, EventArgs e)
      {
              if(this.ApplicationExitEventHandler != null)
                        this.ApplicationExitEventHandler(this, e);
      }

      private void GetSomeData(String SomeCondition)
      {
              _someData = _dataConnection.GetSomeData(SomeCondition);
              _frmMain.SetData(_someData);
      }

      private void SomeCommand(object sender, EventArgs e)
      {
            SomeCommandEventArgs se = e as SomeCommandEventArgs;
            this.GetSomeData(se);
      }
}

class SomeCommandEventArgs
{
     private String _someCondition;
     Public String SomeCondition
     {
           get { return _someCondition; }
           set { _someCondition = value; }
     }
}

In der Program.cs würde es dann wie folgt aussehen:


static class Program
{
	/// <summary>
	/// Der Haupteinstiegspunkt für die Anwendung.
	/// </summary>
	[STAThread]
	static void Main()
	{
		Application.EnableVisualStyles();
		Application.SetCompatibleTextRenderingDefault(false);		
        MainController controller = new MainController();	
        controller.ApplicationExitEventHandler += new EventHandler(ApplicationExit);
		Application.Run();
	}

    static void ApplicationExit(object sender, EventArgs e)
    {
           Application.Exit();
    }
}

Nun meine eigentliche Frage, ist das so akzeptables und eventuell sogar angewandes Anwendungsverhalten im Sinne von MVC?

Wenn nicht, gibt es zu der Programmstruktur negative Meinungen?

Mein Ziel war es in dem Fall die GUI soweit wie möglich von allem anderen zu trennen, um diese ihrer eigentlichen Aufgabe wieder zuzuführen. - Daten anzuzeigen.

Edit: Ich seh grad, dass ich die List als Klasseninstanz gesetzt hab. - In diesem Fall nicht unbedingt notwenig. - In dem Projekt wäre es notwendig, da ich dort auf Änderungen innerhalb der Liste prüfen muss.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

T
381 Beiträge seit 2009
vor 13 Jahren

Ich habe auch meistens einen MainController ähnlich zu deinem.
Jedoch würde ich im Konstrukror nur die Initialisierung machen und dann in einer blockierenden funktion Run() vom MainController Application.Run(_mainForm) aurufen.

In der Program.cs kannst du dir das Application.Run() dann auch sparen.

Und ist das mit dem Application.Exit() im Event ist nicht nötig lass doch den Controller direkt Application.Exit() aufrufen. Oder eben noch einfacher durch Schließen der Form das ende der Run() Funktion erreichen. Dann ist auch ende.

Ich habe bei dem Ansatz aber nie mehr als einen Controller gebraucht.
Ich kann au jeden Fall sagen das aus deinem Ansatz ganz anständige Programme wachsen können (Aus eigener Erfahrung 😃 )

Edit:
Es lohnt sich mehr teile / Schnittstellen des Models an die GUI zu geben und mit Databinding zu arbeiten, als 101 Events für x Datenänderungen im Controller zu bearbeiten.

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 13 Jahren

Naja das Event zum beenden der Anwendung hatte ich so gewählt, damit ich das Run und das Exit in der selben Klasse habe.

Aber an sich stimmt das natürlich, das Application.Run() kann ich auch im Controller aufrufen lassen.

Zu der Sache mit den Events, im aktuellen Projekt reicht das denk ich aus.

Großartig passiert da nicht wirklich was.

Die Form und grad mal ein TabControl mit 3 TabPages ein DataGridView pro TabPage und eine Kategorie Wahl.

Kann man sich so vorstellen, dass z.b. eine TabPage für Verwaltung von Kosten da ist. - Stur anzeigen -> neues hinzufügen -> Eintrag zum löschen Markieren - > Eintrag verändern. Dannach nur noch die Möglichkeit speichern oder andere Kostenkategorie.

Genau genommen hätte ich hier 2 Events, das wechseln der Kategorie und das Speichern der Änderungen.

Ansonsten bei größeren Sachen hast du natürlich recht. - Da würde es mit Events ein wenig spaßig werden.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

L
168 Beiträge seit 2008
vor 13 Jahren

D.h. deine Programmlogik kennt sowohl die GUI als auch die Datenbankzugriffsschicht?

Ist das so klug? Du kannst deinen MainController jetzt niemals in einer anderen Anwendung (bspw. Asp.Net, ...) verwenden.

Eigentlich sollte die GUI nur die Programmlogik kennen. Die Programmlogik nur die Datenzugriffslogik und niemals umgekehrt, das würde nur unnötige Abhängigkeiten schaffen.

C
52 Beiträge seit 2008
vor 13 Jahren

Also wenn man die GUI schon von allem anderen trennen will, dann sollte man meiner Meinung nach auch gleich auf bewährte Patterns wie MVP zurückgreifen.
Ich verstehe nicht, warum immer jeder das Rad neu erfinden muss.
Und zu MVP, MVVM, MVC gibt es mittlerweiel SOOOOOO viele tutorials und schwer zu verstehen und umzustzen ist es ja auch nicht.

Also warum versuchst dus nicht einfach damit?

MfG
Craze

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Craze89,

Also warum versuchst dus nicht einfach damit?

weil MVC - und auch die anderen Muster - nicht so recht zu WinForms passen. Zumindest ist es für normale Business-Anwendungen kein Vorteil, V und C zu trennen, ganz im Gegenteil. MVC hat sich für Windows-Forms-(Business-)Anwendungen also meines Erachtens gerade nicht bewährt. Analog für die anderen genannten Muster.

Mal ganz abgesehen davon, dass es bei den genannten Pattern soviele Varianten gibt, dass es sowas wie das MVC-Muster (analog für die anderen Muster) gar nicht gibt. Das Rad wurde bereits sooft neu erfunden und in SOOOOOO vielen Tutorials unterschiedlich beschrieben, dass es das, was du suggerierst, nämlich feste, bewährte Pattern, gar nicht gibt.

Deinen Rat kann ich also weder nachvollziehen noch gutheißen.

Wenn man normal ereignisorientiert programmiert, wie das in Windows-Forms vorgesehen und Standard ist und dabei auf die Richtung der Zugriffe achtet (also nie vom Modell auf das GUI zugreift), dann bekommt man automatisch eine ausreichende GUI-Trennung, ganz ohne einen der genannten Pattern.

herbivore