Der Einwand gegen das MVVM-Muster ist ein Mangel an IDE-Unterstützung - hilft eines der Frameworks dabei?

Question

Einige unserer Entwickler mögen die Befehle in MVVM nicht, da in der IDE von VS2010 keine Unterstützung für die Navigation von der Befehls-Bindung in XAML zu dem eigentlichen Code, der das Verhalten implementiert, vorhanden ist. Mit Code-Behind können Sie mit der rechten Maustaste klicken und Navigieren zu Event Handler auswählen. Wir beginnen ein neues Projekt mit ungefähr 4 Entwicklern, aber wir teilen die Arbeit typischerweise in funktionale Bereiche auf, nicht Ux und Geschäftslogik, so dass jeder Entwickler im xaml und im viewmodel/domain arbeitet, um die benötigte Funktionalität zu implementieren.

Hältst du das für ein Hindernis für die Einführung von MVVM?

Unterstützt eines der Frameworks in dieser Hinsicht?

Gibt es irgendwelche Tipps/Tricks, die die Navigation erleichtern?

Vielleicht sollten wir versuchen, Arbeit zwischen Ux und App-Logik aufteilen?

Danke für irgendwelche Ideen.

Answer 1

Klingt wie zu mir wimmern, anstatt tatsächliche Kritik an Befehlen oder MVVM. Es erfordert nicht viel Aufwand, MVVM zu implementieren und zu verwenden. Ich habe noch nie ein Framework zur Implementierung von MVVM verwendet.

Ich lege meine Befehle immer an die Spitze meiner Viewmodel-Klassen, gefolgt von öffentlichen Eigenschaften, dem Konstruktor und den Funktionen.

Wenn Sie Probleme haben, sie in Ihrem Viewmodel zu finden, ist Ihre Datei möglicherweise zu lang. Ist es über 1500 Zeilen? Wenn dies der Fall ist, sollten Sie es in mehrere Klassen aufteilen.

Answer 2

Keines der Frameworks hilft bei diesem Problem, weil es normalerweise kein Problem ist. Wenn Sie MVVM verwenden möchten, würde ich vorschlagen, das Team so zu überarbeiten, dass die Arbeit so aufgeteilt wird, wie es MVVM vorschlägt.

Ich arbeite hauptsächlich in VMs und ich habe nie Probleme mit XAML. ... Weil ich es fast nie anfasse. Die Umkehrung gilt für unseren Typ, der unsere Ansichten entwirft. Er arbeitet fast ausschließlich in XAML und schreibt nicht viel C# -Code.