In letzter Zeit habe ich versucht, mich in das neue Zeitalter der UI-Entwicklung zu bringen und ReactiveUI entdeckt zu haben. Ich liebe seine deklarative Natur.
Ich wollte komplett wechseln, also habe ich versucht zu verstehen, wie Dinge in dieser neuen Welt von ReactiveUI gemacht werden. Ich wähle ReactiveUI, weil ich gesehen habe, dass das von einem sehr schlauen Typen (Paul C. Betts) gepflegt wird.
Ich bin sehr neu und ich werde StackOverflow wahrscheinlich mit Fragen darüber überschwemmen, weil ich eine gewaltige Macht habe und ich denke, dass es es verdient, und beherrscht gelernt zu werden.
Kommen wir zu den Details:
Ich habe immer View-First verwendet. Ich bin ein erfahrener Benutzer des Cinch Frameworks ( Ссылка )
Es verwendet MEF, um die ViewModels in jede Ansicht zu injizieren. Sie müssen nur Ihr ViewModel mit [ViewModel ("SampleView")] dekorieren und eine Attached-Eigenschaft zu Ihrer View hinzufügen (ViewModelLocator.ViewModel="SampleView"), und jedes Mal, wenn die View geladen wird, wird das entsprechende ViewModel instanziiert und injiziert DataContext mit dem von Ihnen gewählten Lebenszyklus.
Dieser Mechanismus hat, obwohl er gültig ist, einige Unannehmlichkeiten. Das Schlimmste: Es verwendet einen Locator.
Wie Mark Seemann in seinem Buch vorschlägt, ist ServiceLocator ein Anti-Pattern, das vermieden werden sollte.
Paul wird wahrscheinlich mit der offiziellen Antwort klingeln, aber ich werde meine $ 0,02 als eine Person einsetzen, die den Rahmen für ein paar Projekte benutzt hat, aber keineswegs ein Experte ist.
1) Ich bin ein großer Mark Seemann-Fan und stimme seiner Schlussfolgerung zum ServiceLocator-Anti-Pattern zu. Während ReactiveUI den Locator "Splat" verwendet, würde ich nicht davon ausgehen, dass er auf einer Locator-basierten Infrastruktur aufgebaut ist. Es gibt ein paar globale Elemente, die wie Thread-Scheduler und ein paar wichtige Einstellungen verwendet werden, aber diese werden hauptsächlich beim Start der Anwendung gesetzt (wie bei jedem DI-Container) und Sie behandeln sie nicht direkt in Ihren Klassen. Der einzige tatsächliche Speicherort ist das ViewModelHost -Steuerelement, das eine bestimmte Schnittstelle ( IViewFor ) in Sichten verwendet, um sich gegen ViewModels zu registrieren. Dies ist besser als die Attributmethode, da ViewModels die Views glücklicherweise nicht bemerkt. Aber das passiert in der Steuerung selbst und ist Teil des Frameworks, daher empfinde ich es nicht als Missbrauch des ServiceLocator-Anti-Patterns. Ich denke nicht, dass es etwas anderes ist, als etwas anderes beim Einrichten eines DI-Containers zu registrieren.
2) Nach meiner Erfahrung seit der Verwendung von ReactiveUI sind meine Ansichten sehr einfach geworden. Grundlegend etwas grundlegendes XAML, um das Aussehen und das Layout richtig zu machen, das IViewFor in dem Code dahinter zu implementieren, und alle meine Bindung im Konstruktor auszuführen, was ich jetzt leichter mit ReactiveUI als in XAML finde (obwohl du das immer noch tun kannst, wenn du möchtest). Dann wird alles logisch in den ViewModels gemacht. Ich denke, dass ich in der Regel einen ViewModel First Ansatz allein für die Tatsache, dass ich es (oder zumindest seine Schnittstelle) haben muss, um% Co_de% für es auf der Ansicht zu implementieren definiert. Ich mag die Typüberprüfung und ähnliches (ein weiterer Grund, warum ich gerne im Konstruktor nicht in XAML binde). Aber ich glaube nicht, dass es aus meiner Erfahrung einen starken Grund dafür gibt, so oder so zu handeln.
ServiceLocator ist ein Anti-Pattern, das vermieden werden sollte.
Ich denke generell, dass viele Ratschläge rund um IoC / DI im Bereich der "plattformübergreifenden mobilen Anwendungen" ziemlich schlecht sind, weil man sich daran erinnern muss, dass viele ihrer Ideen für Web-Apps geschrieben wurden, nicht für mobile oder Desktop-Apps.
Zum Beispiel betrifft die überwiegende Mehrheit der beliebten IoC-Container nur die Auflösungsgeschwindigkeit in einem warmen Cache, während die Speicherauslastung oder die Startzeit im Prinzip völlig ignoriert wird - das ist 100% für Serveranwendungen, weil diese Dinge nicht wichtig sind; aber für eine mobile App? Startzeit ist riesig .
Splat's Service Location löst eine Reihe von Problemen für RxUI:
Tatsächlich stimme ich Mark Seemann generell zu, dass Konstruktorin die bevorzugte Methode ist, zu gehen - das ist das Muster, das ich wirklich mag:
%Vor%Dies verwendet eine service-lokalisierte Schnittstelle für die Standardschnittstelle, aber nur, wenn der Aufrufer keine explizite Anweisung im Konstruktor angegeben hat. Es ist viel einfacher, in einem Unit-Test-Runner zu testen, als zu versuchen, einen Schein-IoC-Container zu bauen, aber fällt immer noch auf eine Standardimplementierung zur Laufzeit zurück.
Ob Sie VM-basiertes Routing (d. h. RoutedViewHost, IScreen, RoutingState und Freunde) in ReactiveUI verwenden können, hängt von der Plattform ab, auf der Sie sich befinden:
Tags und Links c# mvvm reactiveui