| 

.NET C# Java Javascript Exception

4
Hallo zusammen

Weiss fast nicht wie ich meine Frage formulieren soll. Hoffe es ist einigermassen verständlich.
Ich beginne mich etwas ernsthafter mit FlowDesign gemäss den beschreibungen von Ralf Westphal zu befassen. Wenn ich seine Ausführungen richtig verstehe, so kann ein Baustein beliebeig viele Ein- und Ausgänge haben, je zwei würden aber kaum überschritten.
Im Bereich der Logik und der Datenadapter zeigen meine wenigen Erfahrungen, dass dem so ist. Wenn ich aber im bereich UI überlege, so stehe ich hier an. Ein Fenster kann viele "Fragen" haben und auch mehrere "Antworten" erwarten. Wenn ich an das Windows Explorer Fenster denke und auf einer Datei das Kontexmenü öffne, so erscheinen da viele Befehle welche ebenso viele Ausgänge des Bausteins zur Folge haben müssten.
Ich persönlich habe grundsätzlich nichts dagegen, dass, wenn nötig, ein Baustein sehr viele Ein- und Ausgänge aufweist. Nur frage ich mich, ob das der richtige Ansatz ist oder in diesem Fall ein Designfehler vorliegt.

Was für Erfahrungen habt Ihr diesbezüglich gemacht?
Vielen Dank für Eure Hinweise.
Andreas
News:
05.06.2012
Andreas Schädler 117 1 6
3 Antworten
1
Interessante Frage. Ich befürchte, dass an dieser Stelle erneut versucht wird, mit dem Ziel der Vereinfachung, mehrere Dimensionen auf einen Nenner zu bringen. Soll heißen: Während sich Flow-Based Programming in einfachen Datenstrukturen wie Datenadaptern, Verarbeitungsklassen, Sensoren etc. beinahe aufdrängt, vergisst man bei GUI-Objekten oft, dass wir hier nicht nur den reinen Datenfluss, sondern auch den User berücksichtigen müssen. Diese "mehrdimensionalen" Inputs auf einen einzigen Eingang zu konzentrieren ist mindestens so schwierig wie die klare Trennung von View und Model. Von Generalisierungen halte ich prinzipiell nichts. Je nach Projekt und Struktur ist das Datenmodell zu wählen. Und da ich sowieso nicht zu den Westphal-Jüngern gehöre wie ich generell von Code-Missionaren wenig halte, orientiere ich mich da an einem praktischen Ansatz. Von Design-Fehler würde ich nur dann sprechen, wenn die Applikation bzw. deren Praktikabilität tatsächlich unter dem gewählten Ansatz leidet, und nicht dann, wenn Gurus daherbeten "das hättest du aber anders machen müssen".
06.06.2012
Celophysis 87 1 5
Ich denke, das Sammeln von vielen Inputs auf einen Eingang ist nicht die Idee von FD. Es würden da unnötige Abhängikeiten entstehen. Die Anwendungsbeispiele sind immer schön klein und übersichtlich, da passt alles immer wunderbar. Aber wie Du sagst, darf man das Ganze nicht zu eng sehen (zu was ich häufig neige und dann auf die Nase falle) und entsprechend den Gegebenheiten nach dem Suchen, mit welchem man sich wohl fühlt.
Vielen Dank für Deine Anwort.
Andreas Schädler 07.06.2012
1
Hallo Andreas,
ich verstehe noch nicht ganz was Du genau in der UI als Baustein also Aktion erstellen möchtest. Die UI ist Startpunkt von Aktionen, die jeweils in einem Flows abgebildet werden können z.B. Start von Befehlt XY im Kontextmenü oder Button 123 wurde geklickt. Daher spricht eigentlich nichts dagegen, dass z.B. dein ViewModel mehrere "Ausgänge" hat, die jeweils einen Flow starten. Wenn z.B. etwas geladen werden soll, sobald sich in der UI etwas ändert, dann starte ich den Flow "Lade dies und das".

In der Dotnetpro gibt es ein paar Artikel, die sich mit MVVM und Flow Design beschäftigen. Vielleicht hilft es dir da weiter.

2011-05 Seite 107 Alles unter einem Hut
http://www.dotnetpro.de/articles/onlinearticle3710.aspx
SuchCode:A1105MVVM

2011-05 Seite 116 Wissen, was zu tun is
http://www.dotnetpro.de/articles/onlinearticle3708.aspxt
SuchCode: A1105dojoLoesung
06.06.2012
KCT 937 1 8
Ich verstehe eben auch noch nicht ganz, aber Deine Antwort hat mich schon viel weiter gebracht. Ich dachte einfach, ein Baustein sollte nicht zu viele Ausgänge haben, aber bei einer UI ist das zwangsläufig der Fall. Wenn ich den Fokus mehr auf die einzelne Funktionalität (Button 123) selbs als auf das implementierende Bauteil lege passt es.
Der erwähnte Artikel in der Dotnetpro ist hilfreich, auch wenn ich nicht alles verstehe. Aber der Hinweis, dass im Bereich UI eine andere Sichtweise angewendet werden muss ist wohl der Schlüsselpunkt meiner Unsicherheit. -->
Andreas Schädler 07.06.2012
--> Dies deckt sich auch mit der Antwort von Celophysis.
Somit habe ich das Gefühl, dass ich jetzt "meinen" Weg der Umsetzung einigermassen klar sehe. Der Rest ist dann Übung und Erfahrung.
Vielen Dank und Gruss
Andreas Schädler 07.06.2012
0
@Andreas: Es sind zwei Arten von Flow-Design Funktionseinheiten zu unterscheiden: Aktionen und Akteure. Schon lange liegt der Fokus bei Flow-Design auf Aktionen, d.h. Tätigkeiten, Handlungen, Verarbeitungen. Tätigkeiten sollen eigentlich nur 1 Input und wenige Outputs haben. Was anderes passt einfach auch nicht zu einer Aktion. Aktionen werden durch Verben bzw. kurze Tätigkeitsbeschreibungen bezeichnet, z.B. "Kunde speichern".

Ziel ist es, Anforderungen als einen Fluss von Aktionen zu modellieren.

Allerdings gibt es auch hier und da Anforderungsaspekte, zu denen besser ein Akteur passt. Akteure haben potenziell viele Inputs/Outputs. Das GUI ist ein typischer Akteur. Akteure werden durch Substantive bezeichnet.

Wenn du Flow-Designs nach EBC übersetzt, dann hat eine GUI-Klasse als FD-Funktionseinheit typischerweise viele Events für die Outputs. Oder mit WPF liegen diese Events dann im ViewModel.

Von da solltest du aber nicht auf andere Funktionseinheiten schließen. Der Grund ist ganz einfach: Funktionseinheiten mit vielen Inputs und Outputs sind meist zustandsbehaftet und schwerer zu testen. Außerdem kann man an ihnen viel schwerer ablesen, wie denn die Funktionsweise der Software ist. Auf welchen Input folgt welcher Output? Solche Verständlichkeit ist aber das Ziel von Flow-Design.

Beim UI ist das aber eher kein Problem. Da stehen Inputs und Outputs in keiner speziellen Beziehung.
15.06.2012
Ralf Westphal 765 1 4

Stelle deine .net-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH