Hallo,
ich schreibe gerade eine kleine private Anwendung, bei der es sich um eine Art Diashow mit mehreren Effekten handeln soll.
Die Effekte sollen per Zufall angezeigt werden.
Bei der aktuellen Architektur handelt es sich um eine Mischung aus Decorator- und Strategie-Paddern.
Ich hab versucht die Architektur im angehängten Bild darzustellen.
Das Frontend wird aktuell über Decorator zusammengesteckt, wobei die jeweilig erforderlichen Daten, im Konstruktur übergeben werden, das führt dazu, dass sich die Konstruktoren für alle Klassen unterscheiden.
Die Instanzen werden über eine Factory erzeugt, die auch die jeweiligen Media-Klassen (also Image, Sound und Text-Files, mit den jeweiligen Filtern erzeugt und den Anzeige-Klassen übergibt).
Dadurch haben wir eine schöne Trennung zwischen den Anzeige-Klassen und dem Auslesen der Daten, auf der anderen Seite wird dadurch die Factory sehr komplex und muss für jede Klasse schauen, wie die erzeugt werden muss und welche Abhängigkeiten bestehen.
Die Anzeige-Klassen wissen natürlich am besten, welche Daten sie benötigen, wenn ich die Respository-Services übergeben würde, könnten sich die Anzeige-Klassen die Daten selber holen, sie benötigt werden, aber dann ist die Trennung zwischen Anzeige und Logik wieder vermischt, aber die Klassen-Instanzierung wäre einheitlich.
Also einfach ausgedrückt, "Logik in Factroy, Trennung von Anzeige" vs "Schlanke Factory und Logik in Anzeige".
Es soll in Zukunft beliebig viele Filter geben können, um für jeden Filter eine eigene Ansicht zu erzeugen, wäre etwsa umständlich, die Filter in der Factory zu erzeugen, macht diese wieder komplexer.
So richtig gut, gefallen mir beide Lösungen nicht, vielleicht übersehe ich auch irgendwas und jemand hat eine Idee, wie man die Architektur deutlich einfach zusammenbauen kann.
cu
Christian
Hast Du Dir mal Reactive Extensions angeschaut?
Damit kann man das Thema sehr sehr sauber abstrahieren und entkoppeln.
Am Ende bleibt natürlich die Frage, "wie perfekt" Du die Lösung haben willst.
Eine Architektur entwickelt sich wie jedes andere Teil einer Anwendung auch weiter..
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Hallo,
hab mich zwar noch nicht intensiv mit ReactiveExtensions beschäftigt, sie sind mir aber bekannt, wie ich das bis jetzt immer verstanden hatte, ist das ein Framework, um auf Antworten von einem Stream, WebService etc zu reagieren, so hab ich das jetzt auch der Website entnommen.
In wie weit mir das bei meinem Problem weiterhilft, hab ich noch nicht ganz verstanden, kannst du dazu evlt noch 1-2 Sätze schreiben?
Vielen Dank
cu
Christian
Antworten von einem Stream, WebService etc zu reagieren, so hab ich das jetzt auch der Website entnommen.
Nein; nicht wirklich. Reactive Extensions ist viiiiiel mehr.
Im Prinzip will ich damit auf entkoppelte Bindungen, Events und Messages hinaus.
Ob am Ende damit eine API getriggert wird oder Deine Business-Logik: völlig egal.
Mit Observable.Generate
kannst dann eine zufällige Liste von Elementen erstellen.
Da ist keine große Architektur (mehr) notwendig; zumindest für diesen Part. Die Architektur selbst ist ja deutlich mehr als dieser Screenshot...
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code