ReactiveUI, View/ViewModel-Injektion und DI im Allgemeinen
In letzter Zeit habe ich versucht, um mich in das neue Zeitalter der UI-Entwicklung und vor ReactiveUI. Ich Liebe das deklarative Natur.
Wollte ich komplett wechseln, also habe ich versucht zu verstehen, wie Dinge gemacht in diese neue Welt der ReactiveUI. Ich wähle ReactiveUI, weil ich gesehen habe, die verwaltet wird von einem sehr klugen Mann (Paul C. Betts).
Ich bin sehr neu, um es, und ich werde wahrscheinlich überschwemmungen StackOverflow Fragen darüber, weil ich eine große Kraft und ich denke, es verdient zu lernen, und gemastert.
Lassen Sie uns in die details:
Habe ich immer benutzt, Sicht-Ersten. Ich bin ein veteran Benutzer die Cinch-Framework (http://cinch.codeplex.com/)
Es nutzt MEF einschleusen des ViewModels zu jeder Ansicht. Sie müssen nur schmücken Sie Ihr ViewModel mit [ViewModel("SampleView")] und fügen Sie eine Angefügte Eigenschaft, um Ihre Ansicht (ViewModelLocator.ViewModel="SampleView"), und wenn die Ansicht Geladen wird, das entsprechende ViewModel instanziert ist und injiziert werden, da seine DataContext mit dem Lebenszyklus, die Sie wählen.
Dieser Mechanismus, es ist zwar gültig, hat einige Nachteile. Das Schlimmste: Es verwendet einen Locator.
Als Mark Seemann schlage vor, in seinem Buch, ServiceLocator ist ein anti-pattern, die vermieden werden sollten.
- Also meine erste Frage ist: ist ReactiveUI gebaut auf der Spitze eines
Locator-basierte Infrastruktur? - Anzeigen-Erste oder ViewModel-Ersten? Was ist besser in Bezug auf gute Praktiken, Entkopplung, stabiles und Sachen wie diese, die Anliegen der eine verrückte, pro-Microsoft Clean-Code-Liebhaber wie mich? Die machen mich besser schlafen und meine Anwendung mit all den *führten Güte?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Paul wird wahrscheinlich Glockenspiel mit der offiziellen Antwort, aber ich werde in meine $0,02 als eine person, die hat, verwendet das framework für ein paar Projekte, ist aber keineswegs ein Experte.
1) ich bin ein großer Mark Seemann-fan und ich nicht einverstanden sind mit seiner Schlussfolgerung über den ServiceLocator anti-pattern. Während ReactiveUI tut, verwenden Sie die Locator - "Splat", ich würde es nicht als gebaut auf der Spitze eines Locator-basierten Infrastruktur. Es gibt ein paar Globale Elemente, die verwendet werden, wie thread-Scheduler und ein paar wichtige Einstellungen, aber diese vor allem bekommen, legen Sie in Anwendung starten (wie jede DI-container) und Sie beschäftigen sich nicht mit Ihnen direkt in Ihre Klassen, zum größten Teil. Die einzige wirkliche Lage ist die
ViewModelHostSteuerung, die über eine spezifische Schnittstelle (IViewFor) auf Ansichten zu registrieren, die gegen ViewModels. Das ist besser als die Attribut-Methode, da es hält die ViewModels selig, nichts von der Aussicht. Aber dies geschieht in der Kontrolle sich selbst und ist Teil des Rahmens, so dass ich nicht das Gefühl, es ist ein Missbrauch der ServiceLocator anti-pattern. Ich habe nicht das Gefühl, es ist anders als die Registrierung noch etwas in der Einrichtung ein DI-container.2) nur meine Erfahrung seit über ReactiveUI, meine Ansichten bekommen haben super-einfach. Im Grunde slap einige grundlegende XAML, um das Aussehen zu erhalten und das richtige layout, Umsetzung der
IViewForim code hinter, und tun alle meine Bindung im Konstruktor, das finde ich einfacher, jetzt mit ReactiveUI als in XAML (obwohl Sie noch können wenn Sie wollen). Dann ist alles Logik-Weise erfolgt in den ViewModels. Ich denke, dass ich in der Regel tun, eine ViewModel-First-Ansatz allein die Tatsache, dass ich muss es (oder zumindest dessen interface) definiert, implementierenIViewFor<>für es auf die Ansicht. Ich mag die Typ-Prüfung und Zeug (ein weiterer Grund warum ich gerne zum binden im Konstruktor nicht in XAML). Aber ich glaube nicht, dass es ist ein starker Grund, es zu tun eine oder andere Weise, aus meiner Erfahrung.Ich generell denke, eine Menge von der Beratung rund um IoC/DI ist ziemlich schlecht in dem Bereich der "cross-Plattform mobile Anwendungen", denn Sie haben sich daran zu erinnern, dass viele Ihrer Ideen wurden geschrieben für web-apps, nicht mobilen oder desktop-apps.
Zum Beispiel, die überwiegende Mehrheit der populären IoC-Container beschäftigen sich ausschließlich mit Auflösung Geschwindigkeit auf einem warmen cache, während im Grunde völlig zu ignorieren Speicherauslastung oder startup - Zeit-das ist 100% gut für server-Anwendungen, denn diese Dinge sind nicht wichtig; aber für eine mobile app? Die Startzeit ist riesige.
Splat-Service-Standort löst eine Reihe von Fragen, für RxUI:
Der beste Weg, um Service-Locator
In der Tat, ich im Allgemeinen Zustimmen, Mark Seemann, in dieser Konstruktor-Injektion ist der bevorzugte Weg zu gehen - das ist das Muster, das ich mag:
Dieser verwendet eine Service-Schnittstelle für die Standard-Schnittstelle, aber nur, wenn der Anrufer nicht geben explizit in den Konstruktor. Weit einfacher test auf eine unit-test-runner als der Versuch, zu konstruieren, ein Trugbild, IoC-container, aber immer noch fällt zurück auf eine default-Implementierung zur Laufzeit.
Anzeigen-Erste oder ViewModel-Zuerst?
Ob Sie mit VM-basierten routing (d.h. RoutedViewHost, IScreen, RoutingState und Freunde) in ReactiveUI hängt von der Plattform ab, Sie sind auf:
Locatorin seiner aktuellen form.