Architektur/Pattern(s)/Framework für UI-Abkopplung

Connbanha mina,

Endlich hab ich wieder Zeit mich der Architektur für die neue Version unserer Software zuzuwenden. Der erste Ansatz der Business-Ebene steht, jetzt muss noch eine UI drauf - naja eigentlich müssen beliebige UIs aufgesetzt werden können.
Und deshalb suche ich nach einer profesionellen Lösung für ein großes Projekt.

Ich habe weder mit UI-Patterns noch mit Softwarearchitektur all zu viel Erfahrung. Daher will ich mich erst mal in die verschiedenen Patterns einarbeiten und schauen welches passt und gut umzusetzen ist. Jetzt hab ich mit MVC/MVP angefangen (sind ja fast gleiche) und hab einen ganzen Tag gebraucht und nur das Pattern verstanden!

Ich befürchte, dass ich auf keinen grünen Zweig komme, wenn ich so weiter mache. Daher wollte ich mal fragen, wer damit schon Erfahrung hat und sie mit mir teilt.

Brennend würden mich folgende Fragen interesieren:

• Welche Patterns gibt es? (ich weis, dass es mehr als MVC und MVP gibt)
• Welche Frameworks gibt es für .NET? Welche sind Aktuell?
• Was würde besonders zu einer SmartClient-Anwendung mit State-Pattern passen?

Danke schon mal an alle, die bis hier her gelesen haben.

Gruß
Juy Juka

PS: Sry, wenn es schon so ein Thema gibt. Mir sind keine guten Suchbegriffe eingefallen. 🙁 Und ich hab nur Themen zu MVC/MVP gefunden.

Hallo JayJuka,

zwei Links die ich Dir dazu gut empfehlen kann wären

MSDN Architecture Center

oder

patterns & practices Developer Center

mfg

Hallo,
ein sehr gutes Buch ist Entwurfsmuster von Kopf bis Fuß von O'Reilly. Das Buch enthalt zwar Java-Code ist aber sehr leicht zu verstehen und auch leicht in C# umzusetzen. Das Buch fängt bei Entwurfsmuster von 0 an, also (fasst) keinerlei Vorkenntnisse gebraucht😉

"Der letzte Schrei" und unter anderem für WPF / Silverlight sehr zu empfehlen ist das MVVM-Pattern (Model, View, ViewModel).

Guten Morgen,

@blackcoin: Danke dir. Ich werd die beiden Bereiche mal durch suche, auch wenn es etwas aussichtslos ist, da ich nicht sicher weis, wonach ich suche.

@kleines_eichhoernchen: Thx. Das Buch hab ich schon seit ein paar Jahren (und auch durch). Es beschreibt aber Designe-Patterns und nur ein Architekturpattern (MVC glaube ich) und dieses ziemlich schlecht. Es ist aber sehr zu empfehlen, die anderen (Designe-)Muster sind super erklärt.

@Golo: Danke schön. Ein weiteres Pattern, das ich mir mal anschauen kann.

So hab gestern noch meinen Büchervorrat geplündert, folgende Patterns für UI-Anbindung hab ich jetzt auf der Liste:

• MVP/MVC (sind so ähnlich, dass ich da keinen unterschied mache)
• Presentation-ABstraction-Controller ( ?( verstehe das wer will, ich noch nicht)
• MVVM

Bleiben noch folgende Fragen:

• Gibts noch weitere Architekturpatterns in dieser "Kategorie"?
• Welche Frameworks für die einzelnen Patterns gibt es für .NET? Welche sind Aktuell?
• Was würde besonders zu einer SmartClient-Anwendung mit State-Pattern passen?

Noch mal Danke an alle, die mir Helfen (oder auch nur den Thread lesen).

Gruß
Juy Juka

Wir setzen CAB/SCSF ein.
Es gibt sowohl für WindowsForms, WPF, WEB alsauch Mobile jeweils eine Version.

Arbeitet eigentlich mit allem, was so bei den Entwurfsmustern derzeit so
bei mehrschichtigen Anwendungen so "angesagt" ist.
MVC / MVP sind möglich/implementiert.
IOC wird verwendet, EventMechanismus, Services und sw alles schon da.

Hallo FZelle,

Danke für die vielen Infos, könntest du die noch mal sortieren, bzw. meine Sortierung korrigieren:

Architektur-Patterns (für UI-Abkopplung):

• IOC
• Services

Frameworks:

• CAB/SCSF (für MVP)

Folgendes konnte ich nicht einordnen und G(oogle) spuckt verständlicher weise nichts brauchbares aus:

• sw
• EventMechanismus

Gruß
Juy Juka

sw -> soweiter

EventMechanismus -> Es ist ein Command und ein EventMechanismus eingebaut.

Du kannst einfach Publisher/Subscriber per Attribute erzeugen, und dadurch
sehr einfach auch in Plugins z.B. auf einen benutzerwechsel reagieren.

Ach ja, Plugins sind auch mit drin.

Am besten einfach mal die HandsOnLabs durchmachen, und mal in dem Forum stöbern.

hi jj

war diese woche beim launch und habe einen vortrag von holger sirtl und jörg jooss zu explizit diesem thema gehört und ein gespräch mit jörg im anschluss geführt.

sehr interessant fand ich das muster pipes and filters.

außerdem regte jörg an, die muster zu vermischen.
so ist es bspw. nicht nur denkbar, sondern oft unbedingt sinnvoll, einen filterknoten durch ein mvc muster zu realisieren.

konkretes beispiel:
aus der datenquelle wird bspw. ein abgeschlossener import gemeldet (import = pipe, ereignismeldung = filter)
der filterknoten für die nächste pipe ist die kontrolle der daten durch einen anwender, der nun ja wieder eine GUI braucht, die als MVC realisiert ist.

die durch den anwender aufbereiteten daten werden in die nächste pipe geschickt, woduch sich wieder ein ereignis ergibt, usw.

s.auch:
Pipes and Filters

ich würde mir auch an deiner stelle den vortrag im web anschauen, sobald die launch vorträge verfügbar sind.
er war am mittwoch den 20. und trug den titel "Entwurf und Aufbau ein er leistungsfähigen Anwendungs architek tur - Schritt für Schritt"

hth
ron

Guten Morgen citizen.ron,

Das Pipes&Filters Muster ist mir bekannt, hab and der betreffenden Stelle das Pattern auch eingesetzt.

Aber mir ist vollkommen unklar, wie Pipes&Filters für UI-Abstraktion verwendet werden kann?!? Ich hab meine Filter (ok, bis jetzt einen), aber wie soll ich da noch eine UI mit dem Pattern anbinden? Der Link war in dieser hinsicht auch nicht sehr informativ, da er nur grob das Pattern erklärt.

Danke und Gruß
Juy Juka

Noch mal Hallo alle zusammen,

Hab nun die bis jetzt genannten Architekturmuster alle angesehen und (hoffentlich) verstanden.
Folgende Muster abstrahieren/entkoppeln die UI nicht (die meisten ignorieren Sie einfach):

• Services
• Pipes&Filters

Das PAC (Presentation Abstraction Controller) Muster beschreibt zwar die Abstraktion/Entkopplung der UI, aber nur am Rande und sehr ... spartanisch. Es ist sogar möglich/gewünscht/... ein anderes Pattern innerhalb des PACs für die UI-Abstraktion zu verwenden.

Folgende Muster enthalten also Umsetzunge für UI-Abstraktion/Entkopplung:

• MVC
• MVP (Weiterentwicklung von MVC)
• MVVM (Spezialform von MVP)

Im Endefekt hab ich keine Wahl ( hört sich schlim an, ist aber eigentlich der best mögliche Fall! 😁 ). Ob ich jetzt MVP oder MVVM einsetze ist gleich, da MVVM aus organisatorischen Gründen einige Nachteile für unsere Firma hat.

Danke noch mal an alle freundlichen und fleisigen Helfe. verbeug

So, nun aber zu meiner verbleibenden Frage:
Gibt es Frameworks für MVVM und/oder MVP in .NET ?
(CAB/SCSF wurde schon von FZelle geannant, ist aber noch ein gutes Stück arbeit, bis ich durch bin 🙂 )

Gruß
Juy Juka

PS: Falls jemand noch ein weiteres Muster kennt, wäre ich natürlich immer noch sehr interesiert!

Bei den vielen ausgefeilten Entwurfsmustern sollte man aber nicht vergessen, dass auch bei Software-Architektur der Grundsatz der Verhältnismäßigkeit gilt. Die großen Pattern spielen ihren Vorteil auch nur bei komplexen Oberflächen aus. Komplex wäre z.B. Visual Studio, Excel oder Outlook.

Für sehr viele Dinge reichen einfache Formulare, die Dienste oder Komponenten konsumieren, aber ansonsten alles im Code des Formulars steht.

Hallo Rainbird,

Du hast recht, aber da bei meiner/unserer Architektur die Oberflächen ausgetauscht werden (WindowsForms, ASP.NET, WPF, etc.) ist das angestrebgte Ziel: Code in Maske = 0%

Gruß
Juy Juka

Wenn Du wirklich eine 100%ige Trennung von Layout und Code haben willst, dann ist MVVM definitiv dafür geeignet.

Gibts den zu MVVM irgendwo ne größere Beispiel App die das einsetzt?

Für WinForms halte ich das MVP für das beste.

Hallo @All,

Nach 2 Jahren wird das Thema tatsächlich aktuell und konkret.
Ich hab noch mal die Suchfunktion verwendet aber keinen aktuelleren Thread zu dem Thema finden können.

Falls jemand neue Erkenntnisse hat, würde ich mich freuen, wenn er/sie diese mit mir teilt.

Gruß
Juy Juka

Naja, in den letzten 2 Jahren sind da ja Frameworks rund um MVVM oder IOC wie die Pilze aus dem Boden geschossen.

Evtl würde es eher helfen wenn du etwas konkretes fragen würdest.

Hallo FZelle,

sehr guter einwand!

Ziele für das UI-Framework:

1. Ansteuerung aller Masken über Generische Interfaces*IObjektControlZugirff<T> - Anzeigen und Editieren eines Objekts des Typs T *IListeControlZugriff<T> - Anzeigen und Auswählen einer Liste von Objekten des Typs T *ISuchParameterControlZugriff<T> - Anzeigen, Ausfüllen und Leeren von Such-Parametern *1 *ISuchControlZugriff<T> - Kombination aus IListeControllZugriff<T> und ISuchParameterControlZugriff<T>

2. Automatisches erzeugen von Form, MenuStip und ContextMenuStrip aus folgenden Quellen, wobei alle höheren Quellen die vorherigen überschreiben*Convention - Wird keine andere Quelle gefunden, werden Standard-Menus erzeugt, die als XML in den Resourcen des Frameworks stehen. *Convention(Xml) - Es werden Standard-Menus aus XML-Dateien erzeug, wenn diese angelegt sind. *Resources - Wenn ein Menü als XML in den Resourcen (der Controls, der Klasse T) unter dem passenden Namen abgelegt ist. *XML - Alle anderen Quellen werden durch XML-Dateien überschrieben, wenn diese den passenden Namen haben.

3. ReadOnly soll von allen Interfaces/Controls/Masken/etc. unterstützt werden

4. Verhalten pro Maske soll über die Konfiguration hinzugefügt werden können. Standard Verhalten:*AufEnterWeiterVerhalten - Enter wird als Tab an die Form weitergegeben, damit man zum nächsten Element springen kann. *VollSelektierungVerhalten - Wird eine TextBox betreten ist der gesamte Text markiert *ListenZustandsSpeicher - Der Benutzer kann Einstellungen an den Listen speichern (z.B. Spalten ein-/ausblenden, gruppieren, etc.) *MaskenZustandsSpeicher - Die Position und Größe und FormState von Masken wird gespeichert.

5. Umschalten zwischen MDI und SDI

6. Alle Menu/ContextMenu einträge sollen in einem anderen Thread laufen, dabei muss die Maske *ReadOnly werden, *sich nicht scließen lassen *usw.

aber *der Benutzer kann auf anderen Masken weiter arbeiten

7. Der Benutzer soll den ToolStrip auf der Maske selbst mit einträgen aus dem MenuStrip füllen können, was gespeichert werden muss.

(optional) 8. Listen sollen Exportiert werden können.

(optional) 9. Alle Controlls sollen abhänig vom angezeigten Typ ermittelt und Ausgetauscht werden können.

Gruß
Juy Juka

PS: @FZelle: Was hat IOC mit einem UI-Framework zu tun (außer natürlich das das UI-Framework IOC verwenden könnte).

Es gibt kein Framework das das alles noch von Hand macht, insofern ist IOC schon ein Thema.
Und da man sich bei einigen Frameworks eben an einen bestimmten IOC bindet muss man da auch schauen.

Was Du hier schreibst sind aber nicht Anforderungen an ein UI-Framework, sondern beinhalten die gesamte Architektur.

Jetzt wäre noch interessant ob das WPF, Web oder WindowsForms werden soll.

Hallo FZelle,

Danke für deine Zeit und Mühe.

Also alle Anforderungen deutet hoch sind in der UI zu lösen. MenuStrip-Aufbau, Verahlten von Steuerelementen, etc. gehört in die UI/Präsentationsschicht und sonst nirgends hin. Natürlich hat die UI/Präsentations-Schicht auch eine Design/eine Architektur - falls du darauf hinaus willst.

Ich suche eben nach einem Framework welches diese Architektur unterstützt (wenn vielleicht auch nur Teilweise).

... WPF, Web oder WindowsForms ...

Am besten wäre natürlich auch hier eine Abstraktion, aber wie weiter oben damals von Rainbird erwähnt muss man auch auf "Verhältnissmäsigkeit" achten und im Zweifelsfall verzichte ich auf diese Abstraktion. Konkret benötige ich im moment ein Windows-Forms-Framework aber ein extram gutes WPF Framework könnte mich überzeugen zu wechseln.

Gruß
Juy Juka

Es gibt kein reines UI Framework wie du es dir vorstellst.

Jedes MVVM/MVP/MVC Framework gibt dir neben den V ( Views ) eben auch den Rest der Architektur mehr oder weniger vor indem es dir da Architekturen bereitstellen.
Auch ist die Annahme das Menüstrip Aufbau und Verhalten von Steuerelementen gänzlich vom UI Framework abhängt auch nicht wirklich richtig.

Und genau deshalb ist es wichtig das Du dir das nochmal genauer anschaust bevor du jetzt wild etwas neu schreibst.

Schau dir dazu z.b. mal CaliburnMicro oder SCSF an.

Guten Tag FZelle,

Danke für die Links so etwas habe ich gesucht. Das da noch was dran hängt, muss ich mir anschauen, ist aber schon mal gut zu wissen.

Auch ist die Annahme das Menüstrip Aufbau und Verhalten von Steuerelementen gänzlich vom UI Framework abhängt auch nicht wirklich richtig.

Aber zu der Aussage muss ich noch mal nachfragen: Was meinst du damit? Natürlich ist die UI dafür verantwortlich die Menüstrips zu erstellen anzuzeigen und so weiter. Das Verhalten ist natürlich auch in der UI definiert/ausgewählt, nur dort nicht programmiert. Meinst du jetzt dynamische Menü-Einträge?

Mit freundlichem Gruß
Juy Juka

Es ist ganz ganz selten das der View den Programmfluss vorgibt, sondern es sind die VM/P/C die dies tun.

Und die geben auch die Stati für die UI for, wie z.b. Enable/Disable von Buttons und ggf auch das dynamische hinzufügen von Eingabemöglichkeiten.
Wie die UI damit umgeht ist ihre Sache ob die da dann Buttons oder Menüs erstellt, Listboxen oder nix.
Ob das wie bei WPF durch Databinding oder bei WindowsForms durch Interaktion stattfindet ist dabei erstmal nebensächlich.

Insofern hängt ein UI Framework nicht wirklich in der Luft/für sich alleine, sondern steht und fällt natürlich mit dem Rest des FW.

Hallo FZelle,

Bei Workflows hast du recht aber es gibt (zumindest bei uns) mehr Masken/Views ohne Workflow, die einfach immer die selben Menüs ausgeben (Speichern, Drucken, etc.).

Aber selbst bei Workflows könnte das UI-Framework eine Schnittstelle definieren, über die der/die Workflows die möglichen Aktionen/Buttons/Enabled-Disabled-Informationen liefert (Microsoft hat sowas ja im PropertyGrid eingebaut).
Daher könnte das UI-Framework "in der Luft hängen".
((Muss aber nicht, hätte ich hier halt gerne.))

Gruß
Juy Juka

Klar kann das jedes Framework, du benutzt nur immer andere Begriffe als der Rest der Welt 😉
Selbst bei den "einfachen" Views mit den Schnittstellen gibt es einen WorkFlow, denn es wird ja immer irgendwas passieren, und wenn es das Schließen des Views selber ist.

Bei den WPF Frameworks wird das per ICommand und deren CanExecute Bindings gemacht.
Bei SCSF gibt es dazu die Commands mit ihrem Status.

Aber bevor du dich entscheidest, musst du eben schauen, was die jeweiligen Frameworks so an Architektur vorgeben.
SCSF basiert z.b. auf dem ObjectBuilder von MS und dann einen weiteren ServiceLocator zu benutzen wäre schade.

Hallo FZelle,

Jetzt hast du mich echt zum Grübeln gebracht, deine letzten zwei Posts haben sich richtig und gleichzeitig verwirrend/falsch für mich angehört, aber ich glaube jetzt hab ich geblickt wo wir an einander vorbei reden.

Für mich gehören VM/P/C (falls du ViewModel, Presender und Controler meinst) noch zur UI schicht und du betrachtest das ganze scheinbar noch feiner als ich. Da ich das noch mit zähle und du nicht, wiedersprechen sich unsere Aussagen garnicht.

Bevor wir uns gleich wieder falsch verstehen: VM/P/C können sich mehrer verschiedene Views (WindowsForms, WPF, Silverlight, ASP.Net, etc.) teilen, wenn das Framework gut genug ist.

Hab ich dich jetzt verstanden?

Gruß
Juy Juka

Du denkst in Schichten, da gehört MVP/MVP/MVVM eher in die Presentationsschicht.

VM/P/C sind hier der UseCase, wenn es für einen bestimmten UseCase mehrere Views gibt, dann kann man den Teilen.
Etwa wie in MonoCross kann man den auch in gewissem Maße Platformunabhängig halten.