Inhalt
- Probleme, mit denen wir uns befassen
- Beispiel Problem
- Naiver Ansatz
- Skalierbar:
- Testbar:
- Wartbar:
- Wiederverwendbar:
- MVC zur Rettung
- Skalierbar:
- Testbar:
- Wartbar:
- Wiederverwendbar:
- Ein Überblick über das, was wir getan haben
Ich habe großes Interesse daran, verschiedene Lösungen für ein Problem zu finden. Derzeit werden verschiedene Architekturen für iOS-Anwendungen untersucht.
Probleme, mit denen wir uns befassen
In fast allen benutzerbezogenen Anwendungen haben wir eine Benutzeroberfläche, Geschäftslogik- und Datenmodule. Und jede Anwendung, die wir entwerfen, soll einfach skalierbar, testbar, wartbar und wiederverwendbar sein.
- Skalierbar: Einer der Skalierbarkeitsfaktoren ist, wie viel Abhängigkeitsmodule voneinander haben. Es ist schwierig, das System zu ändern, wenn der Abhängigkeitsfaktor zwischen Modulen höher ist.
- Testbar: Für Unit-Tests müssen wir einen Teil der Module isolieren, um verschiedene Verhaltensweisen eines Systems zu simulieren (auch als Mocking bezeichnet). Wenn Operationen nicht in Module unterteilt sind oder die Module eng miteinander verbunden sind, wird das Testen sehr schwierig.
- Wartbar: Es zeigt, wie viel Komplexität Ihres Programms mit dem Wachstum der Funktionalität wächst. Wenn die Funktionalität extrem wird, sollten die Verwaltung der Codebasis und ihre Tests einfach bleiben.
- Wiederverwendbar: Dies bedeutet, dass Sie eine Gruppe von Operationen mit dem Namen "Module" erstellen und dieses Modul dann bei Bedarf verwenden, anstatt immer wieder dieselben Operationen zu schreiben.
Beispiel Problem
Betrachten wir dieses Beispiel, um verschiedene Designs zu erläutern. Wir bauen eine Profil-Viewer Anwendung. Es handelt sich um eine Einzelansicht (dh nur einen Bildschirm), die Ihr Profil vom Server abruft und Informationen auf dem Bildschirm anzeigt. Benutzer können ihre Profilinformationen auch über denselben Bildschirm aktualisieren.
Die Qualität jeder Methode, die wir unten diskutieren, wird anhand der oben diskutierten Entwurfsparameter gemessen.
Naiver Ansatz
Wenn Sie mit dem Programmieren noch nicht vertraut sind und kein Framework verwenden, erhalten Sie möglicherweise eine Klasse ProfileView, die alle folgenden Eigenschaften aufweist:
- Profildatenmodell.
- Netzwerkoperationen zum Abrufen und Speichern des Profils.
- Elemente anzeigen, z. Text, Beschriftung, ImageView usw.
Es wird ungefähr so aussehen:
Klasse ProfileView: View {var profile: ProfileDataModel; var nameTxt: TextView; var pic: ImageView; void loadData () void saveData () void render ()}
Lassen Sie uns diese Methode mit unseren Designparametern messen:
Skalierbar:
- Eine Klasse (ProfileView), die alle Aufgaben erledigt, einschließlich Rendern der Benutzeroberfläche, Laden und Speichern von Daten, Datenmodell, Aktualisieren der Benutzeroberfläche und Netzwerkbetrieb.
- Wenn Sie etwas ändern möchten, müssen Sie ProfileView aktualisieren.
- Die Profilansicht kennt die genauen Daten und ihre Quelle, wodurch eine enge Kopplung entsteht.
Testbar:
- Es ist schwierig, die Funktionalität von ProfileView zu verspotten, um Unit-Tests durchzuführen.
- Wir können einige der Funktionen testen und verspotten, indem wir ProfileView unterordnen, wenn die Funktionalität in die richtigen Einheitenfunktionen unterteilt ist.
Wartbar:
- Die Klasse wird auch bei mittleren Funktionen riesig und komplex.
Wiederverwendbar:
- Diese Methode implementiert keinen wiederverwendbaren Code, wie er sein sollte. Beispielsweise kann es Netzwerkoperationen in ein separates Modul extrahieren.
MVC zur Rettung
Dieses Design schlägt vor, die Gottklasse (oben beschrieben) in drei Abschnitte zu unterteilen, d. H. Modell, Ansicht und Steuerung. Jeder Abschnitt hat die folgenden Verantwortlichkeiten:
- Modell: Es enthält die Daten der Anwendung.
- Aussicht: Es wird alles auf dem Bildschirm angezeigt, was dem Benutzer die Interaktion ermöglicht.
- Regler: Es wird Ansicht und Modell zusammenkleben. Es behandelt zwei Dinge: Erstens werden Daten aus dem Modell abgerufen und die Benutzeroberfläche ausgefüllt. Zweitens erhält es Eingaben von View und aktualisiert das Modell.
Es gibt eine Ausnahme zu MVC, d. H. In der Apple-Version von MVC sind Controller und View eng miteinander verbunden, und es ist schwierig, die Ansicht zu verspotten, um die Controller-Klasse vollständig zu testen.
Also jetzt, wenn wir MVC auf unsere anwenden ProfileViewer Anwendung wird es wie folgt aussehen:
Mal sehen, wie diese Methode die vorherige Methode verbessert:
Skalierbar:
- Sowohl Ansicht als auch Modell sind jetzt in der Anwendung getrennt und funktionieren getrennt.
- Ansicht und Modell sind nicht direkt voneinander abhängig.
- Der Controller weiß, woher er Daten bezieht, wie er sie in eine anzeigbare Form konvertiert und die Benutzeroberfläche aktualisiert.
- Der Controller verarbeitet und reflektiert alle UI-Aktionen im Modell.
- Der Controller wird sehr groß, wenn die Ansichten komplex sind.
Testbar:
- Wir können das Modell und die Dienstleistungen separat testen.
- Wir können die Controller und die Benutzeroberfläche testen, indem wir das Modell verspotten.
- Das Testen wird schwierig (nicht unmöglich), wenn der Controller groß wird, z. B. viele Ansichten, Animationen, Listen und Aktionen usw.
- Es ist schwierig, verschiedene Zustände der Benutzeroberfläche zu testen.
Wartbar:
- Da das Design den Code in Module unterteilt hat, ist es einfach, verschiedene Teile zu warten.
- Der Controller wird unübersichtlich, wenn er viele Ansichten, Animationen, Listen und Aktionen usw. erhält.
Wiederverwendbar:
- Wir können verschiedene Ansichten durch dasselbe Modell / dieselben Dienste ersetzen.
- Wenn wir Model über Dienste wie Api Client erhalten, die Network Client verwenden, um Server anzufordern. Alle diese Module können wiederverwendet werden.
Ein Überblick über das, was wir getan haben
In diesem Artikel haben wir Folgendes besprochen:
- Designparameter, die wir erreichen möchten, wenn wir benutzerbezogene Anwendungen erstellen.
- Das Entwerfen von Parametern wirkt sich auf die Qualität der Software aus.
- Was ist der naive Ansatz und wie ist es keine gute Option.
- Was ist MVC und wie verbessert es das Design der Software?
Es gibt andere Entwurfsmuster wie MVP, MVVM, Viper usw., die ebenfalls eine Lösung für dieses Problem bieten.
Ich hoffe, dieser Artikel hat Ihnen geholfen, das Konzept von MVC zu verstehen. Bitte teilen Sie Ihre Kommentare im Abschnitt unten.
