Ist .NET MAUI CommunityToolkit.mvvm icommand eine schlechte Praxis in ViewModel in .net Maui? ⇐ C#

[Anonymous]

Ich habe mit dem MVVM -Muster an einer .NET -Maui -Anwendung gearbeitet und beginne, die übliche Praxis in Frage zu stellen, iCommand -Eigenschaften in ViewModels zu setzen. Während dies der Standardansatz in vielen Tutorials und Beispielen zu sein scheint, bin ich davon überzeugt, dass es gegen saubere Architekturprinzipien verstößt. Mischen von Verantwortlichkeiten < /h3>
ViewModels sollten Mediatoren zwischen Modellen und Ansichten sein, wobei der Schwerpunkt auf Datenumwandlung und Zustandsmanagement liegt. Dennoch werden in ViewModels häufig verhandelt: < /p>

• Navigationslogik (

  Code: Select all

  await Shell.Current.GoToAsync("../")

  )
• UI -Interaktionen (Anzeigen von Warnungen)
• Datenpersistenzvorgänge (Direktdatenbankaufrufe)

Dies scheint das einzelne Verantwortungsprinzip zu verstoßen, indem es Viewmodels zu viel macht. Erhöhte Kopplung < /h3>
Wenn ViewModels Befehle enthalten, die Navigation oder UI-spezifische Operationen ausführen, werden sie eng mit dem UI-Framework gekoppelt, wodurch sie schwieriger zuverwenden oder auf verschiedene Plattformen wiederverwendet werden können. < /P>
3. Testen von Schwierigkeiten < /h3>
Befehle, die Navigation durchführen, Dialoge anzeigen oder mit Framework -Diensten interagieren, erfordern ein umfassendes Verspotten in Unit -Tests, was die Komplexität ergibt und Tests spröde machen kann. < /P>
4. Architekture Klarheit
Sollte in einer sauberen Architektur Daten nicht von Diensten/Repositories und Navigation durch engagierte Navigationsdienste behandelt werden? Warum sollte ein ViewModel Befehle haben, die Daten direkt speichern oder zwischen Seiten navigieren? Änderungen. Eigenschaften von ViewModels zugunsten einer strengeren Trennung von Bedenken? Gibt es erhebliche Nachteile zu diesem alternativen Ansatz, den ich fehlt?>