Mehrere Controller bei MVC-Pattern

Hallo,

mal wieder ne theoretische Frage zur Prammstruktur: Ich verwende eigentlich ganz gern das MVC-Pattern zur Trennung der Oberfläche von den Daten. Mein Problem ist wenn das Projekt größer wird, der Controller ja recht unübersichtlich wird.
Also hab ich mir überlegt das es wohl sinnvoll ist meherere Controller zu verwenden. Soweit eigentlich auch kein Problem. Allerdings gibt es dann ja Oberflächenelemente die von zwei Controllern genutzt werden müssen (z.B. ne Statusleiste,gemeinsam genutztes UserControl, Hauptfenster einer Anwendung usw.). Die Frage ist jetzt wie geh ich eben mit solchen Elementen um die von mehreren Controller genutzt werden? Mach ich daraus ein Singelton oder gibts da was besseres?
Wie würdet ihr sowas lösen oder verwendet ihr nen ganz anderen Ansatz?

Gruß
Snowwolf

Hallo Snowwolf3000,

hm, warum wird denn dein Controller so groß? In einer ereignisgesteuerten Umgebung sollte der ganz klein sein. Die ganze Logik liegt ja in den Modellobjeken oder sollte es tun. Auch wundert mich, dass du schreibst, dass sich zwei Controller einen Statusbar teilen; der Statusbar gehört doch eigentlich in das View.

Natürlich kann es im MVC mehr als einen Controler geben, so wie es auch mehr als ein View geben kann, aber ein Fenster sollte m.E. nur einen Controller und ein View haben.

Bei mir sind Controler und View immer so klein, dass ich sie gar nicht trenne. Ich mache quasi immer M und VC.

herbivore

So noch mal für die doofen (also für mich) 😁
Du trennst View und Controller nicht? Wie funktioniert das? okay wenn ich eine simple Anwendung hab wo nur alles in einen Hauptfenster abläuft dann kann ich alles in die Code-Behind Datei schreiben.
Aber nehmen wir mal an ich will Outlook nachbauen: Dann brauch ich doch ne Menge von UserControls. Dann benötigte ich doch eine zentrale Klasse die mir je nach Bedarf das passende UserControl anzeigt (eins für den Kalender, eins für die Mailansicht usw.) Da muss doch zwangsläufig View und Control getrennt sein.

Ja die Statusbar liegt in der View sogar bei mir. 🙂 Aber der Controller muss die ja trotzdem kennen. Selbst wenn die Logik ausschließlich über Events mit der Statusbar kommuniziert muss ich ja sich die Statusbar für Events der Logikschicht registrieren.

Hallo Snowwolf3000,

Code-Behind klingt nach ASP.NET. Da kenne ich mich nicht aus. Meine Anmerkungen bezogen sich auf WindowForms.

herbivore

Verwendet man den Begriff Code-Behind nur in Zusammenhang mit Asp.net? Also hab mich allgemein auf die Quellcodedatei bezogen mti der eine Form automatisch verknüpft ist(unabhängig von WinForms oder Asp.net). Außerdem sind ja dank .net die Unterschiede zwischen WinForms und Asp.net eh nicht mehr so groß. Sry, wenn ich mich dahin gehnd missverständlich ausgedrückt habe.

Und wenn wir gerade dabei sind was von meinen Ausführungen nicht passt: Hab mir überlegt, das es wohl sinnvoller ist in meinen Outlook-Beispiel die UserControls in Hauptformular der Anwendung zu erzeugen.
Mein Ursprungproblem bleibt aber meiner Meinung nach trotzdem bestehen.

Hallo Snowwolf3000,

aber dann sind doch UserControls das Stichwort zur Reduzierung der Komplexität. Jedes UserControl kann doch für sich MVC implementieren. Dadurch verteilt sich die einstmals zentrale Steuerung auf die einzelnen UserControls.

herbivore

Modell, View, Controller.
Modell=Daten
Controller=Logik
View=Den Kram den der User sieht.
Codebehind(in asp.net) trennt nur statische(reines Html, und JS) und dynamische Daten(on the fly erzeugten Müll wie (darzustellende Daten, Dyn. erzeugte HTML-Controls, Bei Bedarf erzeugtes JS). Es ist im Modell nur als View zu betrachten.
Selbstverständlich is es möglich in der Codebehin-Datei auch andere Sachen zu erledigen als Daten vom Controller anzufordern. Das entspicht dann aber nicht mehr dem MVC-Pattern(Das so gesehen zu allgemein für eine Implementation ist, es ist nur eine Grobbeschreibung). Die Codebehind-Datei(einer ASP.Net-Seite) sollte Imho einen passiven Observer implementieren.
Edit: bei zB: Winforms einen aktiven Observer.

Interessante Diskussion,

ich klink mich mal wieder ein.
In meiner aktuellen Anwendung habe ich ebenfalls eine View, einen Controller und eine dahinter hängendes Domainmodell. Zusätzlich noch eine Komponente zur Abstraktion der Datenzugriffe.

Die Frage die ich mir stelle ist: Sollen alle Zugriffe auf die Domainobjekte über den Controller laufen oder soll die Kommunikation direkt über die Objektschnittstellen stattfinden?

Fall 1: Ich bekomme teilweise redundante Methoden, der Controller schleift die Werte nur durch.
Fall 2: Relativ viel Logik in den Entitäten.

Momentan habe ich einen Mix davon. Der Controller sitzt als Schicht zwischen View und Objektmodell. So kann ich an dem Modell flexibel rumschrauben. IN dem Modell sitzt aber nochmal ein Controllerobjekt, dass die Entitäten verwaltet.

Wie würdet Ihr entscheiden? 🙂

Grüße,
Torsten

Detailliert morgen, ansonsten (als Erstanalyse) sehe ich einen Denkfehler(keinGrund sich zu schämen, das Modell ist schlecht beschrieben).
Domain und Controller(DomainController?)
>Der Controller sitzt als Schicht zwischen View und Objektmodell.
interessant...
Vielleicht kommst du ja auch selbst dahinter...(Die Fakten hast du, interpretier sie nur etwas anders)

viel Erfolg...
ikaros

Windows Forms Anwendungen haben eine Nachrichtenschleife und ein Hauptfenster. Die Nachrichtenschleife läuft so lange wie dieses Fenster existiert. Deshalb kann man sagen:

Am Anfang war das Fenster.

Dieses Fenster kann nun andere Fenster erzeugen, und Controls und alles mögliche. Es kann sich selbst natürlich auch unsichtbar machen. Aber in den meisten Fällen wird dieses Fenster als Haupt-Benutzeroberfläche verwendet. So wie das große Outlook-Fenster mit den vielen Menüs, Symbolleisten, Navigationselementen und Listen. Dieses Hauptfenster hält das/die Model-Objekt(e) und auch die Objekte der Views (UserControls, Dialogfenster, Werkzeugpaletten etc.). Außerdem macht es die einzelnen Views mit dem Model bekannt und steuert den Ablauf (Workflow) der Anwendung (Wann werden welche Controls und Dialoge angezeigt ...). Damit hätten wir den Controller.

Natürlich kann man mehrere solcher "Controller-Fenster" haben. Aber das Programm muss irgendwo "anfangen". Also baut man z.B. ein übergeordnetes MDI-Fenster. Damit hätten wir aber wieder ein Hauptfenster und mehrere Views (Das MVC-Modell lässt sich so schachteln). Diese Hauptfenster sind also Controller und View in einem.

Bleibt noch anzumerken, dass manche Leute das Model (welches den temporären Clientstatus kapselt) mit der Geschäftslogik/Domänenlogik verwechseln.

Hallo Rainbird,

Bleibt noch anzumerken, dass manche Leute das Model (welches den temporären Clientstatus kapselt) mit der Geschäftslogik/Domänenlogik verwechseln

Nicht verwechseln, sondern absichtlich so ansehen. M = Modellobjekte = Business-Objekte = Geschäftslogik. Da MVC ein sehr verbreiteter Pattern ist, gibt es eben verschiedene sinnvolle Interpretationen.

herbivore

@Ikaros,

mann mann, natürlich. Klingt ja auch nicht nur logisch, sondern passt auch logisch zusammen. Es gab aber irgendwelche Gründe weshalb ich diesen Controller noch dazwischen gestopft habe.

Ich muss mir meinen Code nochmal genauer ansehen. Vielleicht fällt mir doch noch eine Rechtfertigung ein 😉

Danke,
Torsten

>Ich muss mir meinen Code nochmal genauer ansehen. Vielleicht fällt mir doch noch eine Rechtfertigung ein 😉

Ich freu mich darauf, Kreativität gepaart mit Logik ist das wichtigste in der Entwicklung(selbst bei Parfüms). Blosswas wissen reicht nicht. Wenn dir was einfällt poste es bitte(schliesslich sind gute Ausreden immer nützlich. Manchmal ist es auch anders und ein Modell erweist sich zu eng...)

Also hab ich jetzt richtig verstanden das bei euch der Controller eigentlich immer auch ein Teil des für die Darstellung zuständigen Objekts ist? (also konkret ein Teil der Hauptform in einer WinForms Anwendnung).

Hallo Snowwolf3000,

so ist es bei mir, aber ich ich habe es so verstanden, dass das einige auch anders sehen.

In engerem Sinne könnte man sogar Application.Run, also die Message-Loop, als eigentlichen Controller sehen. In weiterem Sinne gehören aber natürlich auch die EventHandler dazu.

herbivore

Ich denke mal, das liegt an den Events bei .NET. Es ist einfacher die "On..."-Methoden zu überschreiben und den Controller (der ja eigentlich nur ans Model delegiert) somit mit ins View zu bauen, statt einen extra Controller zu bauen, wie in Java.

Wenn ich hier totalen Mist rede, bitte darauf hinweisen (ich weiß noch nicht, ob ich alles korrekt verstanden habe) 😉
Ich habe in den letzten 1 1/2 Wochen ein Entwurfsmuster-Buch (sehr zu empfehlen: Entwurfsmuster von Kopf bis Fuß) gelesen und erst vor ein paar Tagen das MVC-Pattern kennengelernt.

Mehrere Controller vs ein Controller => PageController vs FrontController

Es gibt beide Konzepte ...

Das MVC-Pattern kommt ursprünglich von Smalltalk 80. Damals hatte man nicht solche universellen Objekte, wie z.B. System.Windows.Forms.Form. Dort hatte der Controller die Aufgabe zentral sämtliche Tastatureingaben entgegenzunehmen (Mäuse waren damals noch nicht so verbreitet). Man wollte die Views schlank halten und nicht in jeder View die ganze Eingabebehandlung einbauen müssen. Der Controller steuerte auch damals den Ablauf (Wann wird dem Benutzer welches View angezeigt). Web Anwendungen gab es sowieso noch nicht.

Das Modell passt also nur teilweise auf unsere modernen Forms und Controls, da diese Benutzereingaben selbst entgegennehmen und verarbeiten. Die verarbeitung der Benutzereingaben in einer ausgelagerten Klasse ergibt bei Windows Forms keinen Sinn. Es würde die Anwendung nur unnötig komplex und langsam machen. Bei Webanwendungen sieht die Sache wieder anders aus (View=HTML welches zum Client geschickt wird, Controller=WebForm Codebehind). Dort haben wir wieder einen Controller, der die Eingaben vom Client entgegen nimmt und entsprechend den Eingaben eine View erzeugt.

Hallo Rainbird,

das hieße aber, dass ich mein Winform-GUI nicht so leicht gegen ein Webfront austauschen könnte, da ich alles nochmal entwickeln muss. Und ich dachte genau das wäre Sinn des MVC. Schneller Austausch der Komponenten?

Grüße
Torsten

Da es damals (1980) noch keine Webanwendungen gab, kann das auch nicht der Sinn sein. Forms- und Webanwendungen sind zu verschieden, um sie unter einen Hut zu bringen. Deshalb bin ich auch der Meinung, dass das Model nicht die Geschäftsregeln implementieren soll. Die Geschäftslogik sollte von der Anzeige und der Anzeigetechnologie unabhängig sein. Dafür sorgen n-Tier Enterprise Model / Service Oriented Architecture, aber nicht MVC. MVC ist ein Pattern, welches die Architektur der Anzeigeschicht beschreibt.

So sollte meiner Meinung nach eine Anwendung aufgebaut sein:

Datenbank/Persistenz

Geschäftslogik

Präsentationslogik (Hier setzt MVC an)

Mit dieser Architektur können z.B. ein Web und ein Forms-Client die selbe Geschäftslogik und die gleiche Datenbank benutzen.

Also hab ich jetzt richtig verstanden das bei euch der Controller eigentlich immer auch ein Teil des für die Darstellung zuständigen Objekts ist? (also konkret ein Teil der Hauptform in einer WinForms Anwendnung).

Nein der Contrloller implementiert die Logik. Die Art des Frontends ist dem Controller egal. Bei nem Webfrontend ist eine passive Umsetzung eines Patterns eher praktikabel als bei einer Lokalen App(Aktualisierung bei Nachfrage). Bei Winforms(.Net) ist ein EventPattern fast Mode(muss aber nicht notwendig sein). Ein DarstellungsObjekt kann auch pollen, das Eventpattern hat sich aber in dem Bereich als simple und leicht zu handhabende Methode bewährt. Ein Webfrontend kann damit kaum umgehen, und meist ist Polling die bessere Lösung(es gibt Ausnahmen und die sind (meist) schwer umzusetzen. Das betrifft aber nur die View niemals den Controller. man kan den Controller nat. insoweit modifizieren das er die View unterstützt, das würde ich aus prakt. Erfahrungen jedoch ablehnen und in einem zusätzlichen Layer der View implementieren(nur wenn absolut notwendig). Mit dem Controller hat das(oder sollte) nichts zu tun.

Bei mir ist es jetzt in etwas so: (siehe Anhang)

Die GUI pollt allerdings nur, das ist wohl noch ein Überbleibsel aus Webentwicklungszeiten. Dadurch muss ich etwas mehr entwickeln, kann aber tatsächlich auf bspw. Webfronts umsteigen.

Die Controller-Komponente enthält sowohl den Main-Controller, der bswp. mit meinen Schnittstellen nach aussen kommuniziert. (Dateizugriffe und ein externes Rechenmodul welches mir Werte liefert.) Der Domain-Controller verwaltet meine Entity-Klassen im Domain-Modell. Die dritte Controller-Klasse enthält alle sonstigen Datenzugriffe. (Combobox-Einträge und mehr.)

Datenbank-Klasse, Domain-Modell und Schnittstellen sollten von Anfang an austauschbar sein, deshalb sind sie kein Bestandteil des Controllers.

Das ist nur ein kurzer grober Überblick über die Architektur von der ich eingangs sprach.

Viele Grüße,
🙂 Torsten