WPF-Programmiermethodik

Nach 3 Monaten, in denen ich meine App auf WPF programmiert habe, habe ich mir überlegt, wie ich meine App programmieren soll (ich weiß, dass es vielleicht zu spät ist). Auf meiner APP verwende ich eine API einer Software, die mein Tool verwaltet. Ich habe DAL, die 16 classn enthalten, davon sind 3 Singles. Ich habe etwas Logik in den .cs Dateien und XAML ist natürlich weg. Meine Frage ist, ich sehe viele Kommentare, dass eine App, die in WPF geschrieben wurde, MVVM verwenden sollte, und dies wird den Code brauchbarer und lesbarer machen, kann ich meinen Code in MVVM verwandeln? Was ist die eigentliche Bedeutung von MVVM (nicht Wikipedia oder manuelle Definition)?

Ich benutze auch SQL-Abfragen und ich lese ein Papier über EF (Entity Framework), können MVVM und EF koexistieren im selben Projekt?

Ich weiß meine Frage ist ein bisschen Neuling Frage (Ich bin Neuling: P) und eine abstrakte Frage, aber ich möchte wissen, dass die App, die ich schreibe, das Beste sein wird, was ich zu dieser Zeit schreiben kann 🙂

   

Die eigentliche Bedeutung von MVVM ist: UI ist nicht Data. Daten sind Daten, UI ist UI .

Dies bedeutet, dass Sie die Anwendung nicht so entwickeln sollten, dass die Programmlogik (oft als Geschäftslogik bezeichnet) eng gekoppelt ist oder vom Status der UI-Komponenten abhängig ist, sondern vom Status der Datenelemente abhängt (sei es das Modell) oder das Ansichtsmodell).

In anderen Frameworks (z. B. Winforms) fügen Sie normalerweise einen Click-Ereignishandler zur Schaltfläche hinzu, wenn Sie einen Bildschirm mit einem Textfeld und einer Schaltfläche haben, und dann den Text aus dem Textfeld lesen. In MVVM sollte die Text-Eigenschaft der TextBox an eine Zeichenfolgeneigenschaft im ViewModel gebunden sein, und die Schaltfläche sollte ebenfalls an einen Befehl im ViewModel gebunden sein.

Dies ermöglicht eine Abstraktion der UI (welches das ViewModel ist), so dass, wie gesagt, Ihre Anwendungslogik nicht von der UI, sondern von einer Abstraktion abhängig sein kann.

Dies ermöglicht eine enorme Skalierbarkeit in der Benutzeroberfläche und der Logik und ermöglicht auch die Testbarkeit mehrerer Aspekte des Verhaltens der Benutzeroberfläche, da ein großer Teil des Verhaltens der Benutzeroberfläche im ViewModel definiert ist.

Es gibt auch andere Aspekte von MVVM, aber die Haupterkenntnis ist, dass.

Bearbeiten:

Ich werde ein konkretes Beispiel für die Vollständigkeit der Antwort hinzufügen:

1 – Nicht MVVM WPF:

XAML:

     

Code dahinter:

 private void Button_Click(object sender, EventArgs e) { //Assuming this is the code behind the window that contains the above XAML. var lastname = this.txtLastName.Text; //Here you do some actions with the data obtained from the textbox } 

2 – MVVM WPF:

XAML:

        

Ansichtsmodell:

 public class MyViewModel { public string LastName { get; set; } public Command MyCommand { get; set; } public MyViewModel() { // The command receives an action on the constructor, // which is the action to execute when the command is invoked. MyCommand = new Command(ExecuteMyCommand); } private void ExecuteMyCommand() { //Only for illustration purposes, not really needed. var lastname = this.LastName; //Here you do some actions with the data obtained from the textbox } } 

Wie Sie im obigen Beispiel sehen können, enthält das ViewModel keinen Verweis auf die View. Daher kann die Ansicht beliebig sein, solange die {Bindings} beibehalten werden.

Der Leim, der sie magisch zusammenbringt, ist die DataContext Eigenschaft von WPF-UI-Elementen, die das Objekt ist, gegen das alle Bindungen getriggers werden.

Es gibt andere Dinge, z. B. die Eigenschaft Änderungsbenachrichtigung im ViewModel, um bidirektionale Bindungen zu aktivieren, dies liegt jedoch außerhalb des Bereichs dieser Antwort.

Bedenken Sie auch, dass MVVM ein Entwurfsmuster ist, während WPF ein Framework ist. MVVM wird derzeit auch in anderen Technologien eingesetzt (derzeit gibt es eine Menge Buzz über MVVM für das Web, mit JavaScript und so)

Ich schlage vor, dass Sie die in anderen Antworten erwähnten Bücher sowie dieses Tutorial für weitere WPF-spezifische Aspekte lesen.

Meine Frage ist, ich sehe viele Kommentare, dass eine App, die in WPF geschrieben wurde, MVVM verwenden sollte, und dies wird den Code brauchbarer und lesbarer machen, kann ich meinen Code in MVVM verwandeln?

Es gibt keine Anforderung, dass Sie das MVVM-Muster verwenden müssen – keine. Sie müssen die Komplexität der App, die Sie erstellen, und die Fähigkeiten der Entwicklungsgruppen berücksichtigen. Wenn es sich um eine kleine oder kleine / mittlere App handelt, ist MVVM im Allgemeinen übertrieben. Wenn die Fähigkeiten / Talente der Gruppe nicht gut zu einem getrennten Präsentationsmuster passen, ist MVVM möglicherweise keine gute Entscheidung.

Wenn es richtig gemacht wird, gibt Ihnen MVVM alle Vorteile, von denen Sie gelesen haben. Umgekehrt kann es, wenn es falsch gemacht wird, ein Albtraum für Entwicklung und Unterhaltung sein – definitiv nicht lesbarer und brauchbarer. Aus meiner persönlichen Erfahrung heraus ist es einfacher, an einer schlecht geschriebenen Code-Behind-App als an einem schlecht geschriebenen MVVM-basierten Programm zu arbeiten.

Sicher, Sie können Ihre aktuelle App auf das MVVM-Muster umschreiben. Entfernen Sie einfach Ihren Code-Behind und legen Sie ihn in Ihre View-Modelle, Hilfsklassen, Repository-classn, Biz-Logic-classn usw. Fallen Sie nicht in die Falle, alles in Ihre View-Modelle zu stecken und einen MVVM-verherrlichten Code zu erstellen -hinter.

Ich benutze auch SQL-Abfragen und ich lese ein Papier über EF (Entity Framework), können MVVM und EF zusammen im selben Projekt?

Sicher, sie können. Denken Sie daran, dass EF eine Datenzugriffstechnologie ist und MVVM ein Entwurfsmuster ist. Sie werden wahrscheinlich EF in Ihren DAL-classn verwenden, die Sie erwähnen.

Ein letzter Gedanke, wenn Sie sich entscheiden, die MVVM-Route zu gehen, dann sollten Sie überlegen, ein Framework zu verwenden, das es erleichtert, wie Prism . Oh, und seid bereit für ein bisschen Lernen und Frustration.

Ich würde definitiv DependencyInjection mit einem Framework wie Unity untersuchen .

Ihre Singleton-classn können mit einem DependencyInjection-Container registriert und in Konstruktoren anderer classn (z. B. ViewModels) eingefügt werden. So könnten andere DAL-classn regelmäßig instanziiert und in classn eingefügt werden.

DependencyInjection ist das wichtigste Entwicklungsmuster bei der Entwicklung großer Unternehmenssoftwareanwendungen und ist sowohl für Client- als auch für Servercode anwendbar. MVVM ist ein nettes Muster, wird aber das Problem der gesamten Anwendungskomplexität in Bezug auf die Abhängigkeitskopplung nicht behandeln.

Dies sind meine spezifischen MVVM

1) Erhöht die “Blendbarkeit” Ihrer Ansichten (Möglichkeit, Expression Blend zum Entcasting von Ansichten zu verwenden). Dies ermöglicht eine Trennung der Verantwortlichkeiten von Teams, die das Glück haben, einen Designer und einen Programmierer zu haben … jeder kann unabhängig von dem anderen arbeiten.

2) “Lookless” Ansichtslogik. Ansichten sind unabhängig von dem Code, der hinter ihnen ausgeführt wird, sodass dieselbe Ansichtslogik für mehrere Ansichten wiederverwendet werden kann oder eine Ansicht problemlos umgerüstet oder ersetzt werden kann. Trennt Anliegen zwischen “Verhalten” und “Stil”.

3) Kein duplizierter Code zum Aktualisieren von Ansichten. In code-behind werden viele Aufrufe von “myLabel.Text = newValue” überall angezeigt. Mit MVVM können Sie sicher sein, dass die Ansicht entsprechend aktualisiert wird, indem Sie die zugrunde liegende Eigenschaft und alle zugehörigen Nebeneffekte festlegen.

4) Testbarkeit. Da Ihre Logik Ihrer Ansicht vollkommen unwissend ist (keine “myLabel.Text” -Referenzen), können Komponententests leicht durchgeführt werden. Sie können das Verhalten eines ViewModels testen, ohne seine Ansicht einzubeziehen. Dies ermöglichte auch eine testgetriebene Entwicklung des Ansichtsverhaltens, was mit Code-Behind nahezu unmöglich ist.

Die anderen zwei Muster sind in Bezug auf die von ihnen angesprochenen Probleme wirklich getrennt. Sie können MVVM mit MVP und MVC verwenden (die meisten guten Beispiele da draußen machen eine Form davon).

Tatsächlich ist MVP (mit passiver Sicht und nicht mit einem überwachenden Controller) meiner Meinung nach nur eine Variante von MVVM.