MVC für Desktop-App ohne Datenschicht

Question

Frage könnte schwierig sein (wegen seiner Natur oder meiner Art, es zu beschreiben), also lies das wirklich, bevor du antwortest.

Ich habe diese App zu schreiben:
a) Desktop-App;
b) keine Datenschicht im Sinne von Datenbank, Dateien oder einem anderen Repository (keine Speicherung, Speicherung oder Laden von Daten);
c) App wird einige Berechnungsalgorithmen implementiert haben (Genetic Algorithm);
b) stellt eine GUI zur Verfügung, die Steuerelemente für App- und Berechnungsergebnisse anzeigt.

Ich denke über die Verwendung von MVC-Muster, aber ich habe Zweifel, wie man es benutzt. Da ich keine Datenschicht im Sinne von (zum Beispiel) Datenbank habe (Daten werden während der Ausführung auf der Basis von Benutzereingaben erzeugt), mache ich mir Gedanken über die Verwendung von MVC in dieser Implementierung. Bis jetzt bin ich mit zwei Annäherungen gekommen:

1. GUI ist die Ansicht. GeneticAlgorithm ist der Controller. GeneticAlgorithmResults ist das Modell (als Klasse, die nur Daten speichert). Grundlegender Fluss:

   • Die Ansicht sendet Benutzereingaben an den Controller;
   • Der Controller verarbeitet Benutzereingaben und generiert Daten;
   • Der Controller sendet generierte Daten an das Modell;
   • Das Modell benachrichtigt die Ansicht über neue Daten;
   • Die Ansicht zieht neue Daten und aktualisiert die Anzeige.

2. GUI ist die Ansicht. AppEngine ist der Controller. GeneticAlgorithm nad GeneticAlgorithmResults sind das Modell. Jetzt haben wir:

   • Die Ansicht sendet Benutzereingaben an den Controller;
   • Der Controller verarbeitet Benutzereingaben und sendet Steuersignale an das Modell.
   • Das Modell aktualisiert seinen internen Status (generiert neue Daten);
   • Das Modell benachrichtigt den Controller über neue Daten;
   • Der Controller zieht Daten zum Modell;
   • Der Controller verarbeitet Daten;
   • Der Controller sendet verarbeitete Daten an den View;
   • Die Ansicht aktualisiert die Anzeige.

Erster Ansatz scheint einfacher und eher wie MVC zu sein. Das Problem ist, dass einige Logik im Modell sein müsste - entscheiden Sie, wann das Modell benachrichtigt werden soll, da nicht alle Datenaktualisierungen angezeigt werden, oder dass die Anzeige mit den Datensätzen nicht mit jeder kleinen Änderung aktualisiert wird. Diese Entscheidungen basieren auf Benutzereingaben. Was mehr ist, kann eine zusätzliche Verarbeitung der Daten vor der tatsächlichen Anzeige erforderlich sein. Dies wäre in der Ansicht.

Auf der anderen Seite scheint der zweite Ansatz komplizierter zu sein und es sieht so aus, als würden viele Nachrichten übergeben, um die Aufgabe zu erfüllen.Aber es gibt dem Controller volle Kontrolle über Logic und trennt die Verantwortlichkeiten der View, des Controllers und des Modells (was der Hauptzweck von MVC ist).

Welchen Ansatz würden Sie empfehlen? Oder sollte ich sie vielleicht mischen und erste Anflugarchitektur mit Kommunikationsfluss vom zweiten Ansatz verwenden? Oder ein anderes Design?

Answer 1

Von meinem Verständnis von MVC, ist die zweite Version mehr wie das strenge MVC-Paradigma. Aber einer meiner sehr intelligenten Lehrer hat mir einmal gesagt, dass die Designmuster da sind, um einen lockeren Satz von Richtlinien zu geben, und nicht notwendigerweise dazu gedacht sind, nach dem T. zu folgen. Meiner Meinung nach ist eine Mischung aus beidem. A gute Idee. Wenn eine Logik in das Modell eindringt, ist das nicht das Ende der Welt, es bedeutet nur, dass Sie vorsichtiger sein müssen, um die Trennung Ihrer Komponenten im Auge zu behalten. Wenn eine kleine Änderung an MVC Ihr Leben 50% einfacher macht (weniger Nachrichtenaufwand), dann ist es wahrscheinlich eine gute Idee.

Answer 2

Ich würde definitiv mit etwas näher an der zweiten Implementierung gehen. Ja, es scheint, als würden mehr Nachrichten hin- und hergeschickt, aber wenn Ihre Anwendung wächst und sich ändert, werden Sie froh sein, dass Sie die Anwendung mit kleinen Klassen erstellt haben.

Überlegen Sie: Wo ist die Logik, um alltägliche Aufgaben wie das Wechseln zwischen Algorithmen, das Ausführen von ihnen und das Verarbeiten der Daten zum Anzeigen zu erledigen?

Genetische Algorithmen arbeiten mit irgendeiner Art von Eingabe- oder Startdaten, nicht wahr? Sie würden dies von Ihrer Datenzugriffsebene erhalten. Benötigen Sie keine Seed-Daten oder Initialisierungsbedingungen? Wie wäre es, wenn Sie Ihre Ergebnisse in einer Datei speichern und später zur Überprüfung abrufen würden? Ich würde denken, dass Sie dies tun müssen, sobald Ihre Anwendung reift. Erwarten Sie, dass Sie zunächst dateibasierte Persistenz verwenden. Wenn Sie dazu bereit sind, können Sie später auf eine Datenbank aktualisieren. Wenn Sie mit einer abstrahierten Datenpersistenzschicht codieren, müssen Sie die Geschäftslogik später nicht mehr ändern, um den Wechsel von Datei zu Datenbank zu unterstützen.

Sie sollten das Strategie-Pattern verwenden, um Ihre Algorithmen zu implementieren. Dadurch können Sie die Implementierung Ihres Solvers vom genetischen Algorithmus in Ihre anderen Algorithmen ändern, ohne die Geschäftslogik für jeden Algorithmus ändern zu müssen.

Die Business-Schicht wird einen ISolver sehen, der Eingaben empfängt, und Sie werden mySolver.Solve() aufrufen. Sie sollten zwischen den verschiedenen Versionen wechseln können, ohne die Business-Schicht-Logik ändern zu müssen (Open Closed Principle). Der einzige Unterschied in der Art, wie die Geschäftslogik mit den Algorithmen interagieren sollte, sollte im Konstruktor liegen, und selbst dort sollten Sie ein Factory-Muster verwenden.