MVVM mit Unity und Unit Testing Architekturentwurf

Das Wichtigste zuerst ... Wie Sie festgestellt haben, ist Ihre aktuelle Konfiguration möglicherweise problematisch beim Testen von Einheiten (komplexe VM-Initialisierung). Allerdings macht das DI-Prinzip , hängt von Abstraktionen ab, nicht von Konkretionen , macht dies Problem gehen sofort weg. Wenn Ihre Ansichtsmodelle Schnittstellen implementieren und Abhängigkeiten über Schnittstellen realisiert werden, wird jede komplexe Initialisierung irrelevant, da Sie im Test einfach Mocks verwenden.

Als Nächstes besteht das Problem bei annotierten Eigenschaften darin, dass Sie hohe Kopplung zwischen Ihrem Ansichtsmodell und Unity erstellen (daher ist es höchstwahrscheinlich falsch). Idealerweise sollten Registrierungen an einem einzelnen Punkt auf der obersten Ebene behandelt werden (was in Ihrem Fall der Bootstrapper ist), so dass der Container in keiner Weise an das Objekt gebunden ist, das er bereitstellt. Ihre Optionen # 3 und # 4 sind die häufigsten Lösungen für dieses Problem mit wenigen Anmerkungen:

• zu # 3 : Zu viele Konstruktorabhängigkeiten werden normalerweise gemildert, indem allgemeine Funktionen in Fassadenklassen (aber 4 ist nicht so viele immerhin). In der Regel hat ordnungsgemäß entworfener Code dieses Problem nicht. Beachten Sie, dass abhängig von Ihrem MainViewModel möglicherweise nur die Abhängigkeit von Liste der untergeordneten Ansichtsmodelle erforderlich ist, keine konkreten.
• bis # 4 : In Komponententests sollten Sie keinen IoC-Container verwenden. Sie erstellen einfach Ihre MainViewModel (via Ctor) manuell und injizieren Mocks von Hand .

Ich möchte noch einen weiteren Punkt ansprechen. Überlegen Sie, was passiert, wenn Ihr Projekt wächst. Das all Packen von Modellen in ein einzelnes Projekt ist möglicherweise keine gute Idee. Jedes View-Modell hat seine eigenen Abhängigkeiten (oft nicht verwandt mit anderen), und all diese Dinge müssen zusammensitzen. Dies könnte sich schnell als schwierig erweisen. Denken Sie stattdessen darüber nach, ob Sie einige allgemeine Funktionen (z. B. messaging , tools ) extrahieren und in separaten Projektgruppen (wiederum in M-VM-V-Projekte) aufteilen können ).

Außerdem ist es viel einfacher, Ansichten auszutauschen, wenn Sie eine funktionsbezogene Gruppierung haben. Wenn die Projektstruktur so aussieht:

Wenn Sie eine andere Ansicht für das Bearbeitungsfenster des Benutzers ausprobieren, müssen Sie eine einzelne Assembly erneut kompilieren und austauschen ( User.Views ). Mit all in one bag Ansatz müssen Sie viel größere Teile der Anwendung neu erstellen, auch wenn sich die Mehrheit nicht geändert hat.

Bearbeiten: Denken Sie daran, dass Ändern der bestehenden Struktur des Projekts (auch winzig) ist in der Regel ein sehr teurer Prozess mit kleineren / keine Geschäftsergebnisse. Es ist Ihnen vielleicht nicht erlaubt oder einfach nicht möglich, dies zu tun. Verwendung -basierte (DAL, BLL, BO usw.) Struktur funktioniert , es wird mit der Zeit immer schwerer. Sie können auch den gemischten Modus verwenden, mit Kernfunktionen gruppiert nach ihrer Verwendung und einfach neue Funktionen hinzufügen, die einen modularen Ansatz verwenden.

Zunächst möchten Sie vielleicht eher Interfaces als konkrete Klassen verwenden, damit Sie beim Unit-Testen die Mock-Objekte übergeben können, also IToolboxViewModel anstelle von ToolboxViewModel , etc.

Davon abgesehen würde ich die dritte Option - Konstruktorinjektion - empfehlen. Dies ist am sinnvollsten, da Sie sonst var mainVM = new MainViewModel() aufrufen und mit einem nicht-funktionalen View-Modell enden könnten. Dadurch machen Sie es auch sehr einfach zu verstehen, was die Abhängigkeiten Ihres Ansichtsmodells sind, was es einfacher macht, Komponententests zu schreiben.

Ich würde diesen Link überprüfen, da er für Ihre Frage relevant ist.

Ich stimme Lesters Punkten zu, möchte aber einige weitere Optionen und Meinungen hinzufügen.

Wo Sie das ViewModel über den Konstruktor an die View übergeben, ist das etwas unkonventionell, da die Bindungsfunktion von WPF Ihnen ermöglicht, das ViewModel vollständig von der View zu entkoppeln, indem Sie es an das DataContext-Objekt binden. In dem von Ihnen beschriebenen Design ist die View an eine konkrete Implementierung gekoppelt und begrenzt die Wiederverwendung.

Während eine Service-Fassade Option 3 vereinfacht, ist es nicht ungewöhnlich (wie Sie bereits beschrieben haben), dass ViewModels der obersten Ebene viele Verantwortlichkeiten haben. Ein anderes Muster, das Sie berücksichtigen können, ist ein Controller- oder Factory-Muster, das das Ansichtsmodell zusammenfügt. Die Fabrik kann durch den Container unterstützt werden, um die Arbeit zu erledigen, aber der Container wird vom Anrufer abstrahiert. Ein Hauptziel beim Erstellen containergesteuerter Apps besteht darin, die Anzahl der Klassen zu begrenzen, die verstehen, wie das System zusammengesetzt ist.

Ein weiterer Punkt betrifft die Anzahl der Verantwortlichkeiten und Objektbeziehungen, die zum Viewmodell auf oberster Ebene gehören. Wenn Sie sich Prism ansehen (ein guter Kandidat für WPF + Unity), wird das Konzept der "Regionen" eingeführt, die von Modulen bevölkert werden. Eine Region kann eine Symbolleiste darstellen, die von mehreren Modulen ausgefüllt wird. Bei einem solchen Entwurf hat das Top-Level-Viewmodel weniger Verantwortlichkeiten (und Abhängigkeiten!) Und jedes Modul enthält Unit-testbare DI-Komponenten. Große Verschiebung des Denkens von dem Beispiel, das Sie zur Verfügung gestellt haben.

In Bezug auf Option 4, bei der der Container durch den Konstruktor übergeben wird, ist eine technische Abhängigkeitsinversion, jedoch in Form eines Servicestandorts anstelle einer Abhängigkeitsinjektion. Nachdem ich diesen Weg gegangen bin, bevor ich dir sagen kann, dass es ein sehr rutschiger Abhang ist (mehr wie eine Klippe): Abhängigkeiten sind in Klassen versteckt und dein Code wird zu einem Netz von "just in time" -Wahnsinn - völlig unberechenbar, absolut untestabil.