You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 

63 lines
6.8 KiB

\section{Redux}
\label{eval:redux}
Riverpod stellt eine externe Bibliothek zur Zustandsverwaltung dar, welche auf Ansätzen aus dem React-Umfeld basiert. Die Grundlagen dazu sind im \autoref{sec:redux} nachzuvollziehen.
\subsection{Implementierung}
Für die Implementierung mit Redux wurden die Bibliotheken redux in der Version 5.0.0 und flutter\_redux in der Version 0.8.2 genutzt.
Anstelle von mehreren Zuständen wurde hier ein zentraler Zustand implementiert, der auch als Store bezeichnet wird. Um Änderungen an diesem Store durchzuführen wurden diverse Actions definiert wie beispielsweise eine Action für den Anmeldevorgang. Diese Actions werden von Reducern verarbeitet, welche in diesem Fall immer einen Teilzustand des zentralen Zustands verändern.
Für den Abruf der Daten für die Produktliste wurde eine Middleware implementiert. Diese erhält von der Bibliothek alle Actions, bevor diese von einem Reducer bearbeitet werden. Die Middleware führt im Falle, dass eine entsprechende Action ausgelöst wird, die Netzwerkzugriffe durch und emittiert danach entsprechende Actions, welche durch Reducer die Daten in den Store übermitteln. Middlewares sind notwendig, da Reducer keine asynchronen Operationen durchführen sollen, da diese keine Nebeneffekte haben dürfen und bei gleicher Eingabe immer das gleiche Ergebnis liefern müssen. \autocite[vgl.][Kap1.3.3]{redux}
Für die Einbindung in die Benutzeroberfläche kommen zwei verschiedene Möglichkeiten zum Einsatz. Zum einen existiert der StoreConnector, welcher einen bestimmten Teil des zentralen Zustands selektiert und diesen an ein Widget weitergibt. Zum anderen gibt es den StoreBuilder, welcher den kompletten Store an ein Widget weitergibt. Der StoreConnector wird hauptsächlich bei trivialeren Einsatzgebieten verwendet, die nur das Auslesen einer Variable aus dem Store benötigen. Der StoreConnector hingegen bei komplexeren Fällen, die beispielsweise auch Actions depeschieren müssen.
\subsection{Bewertung}
Im folgenden Abschnitt wird die Implementierung mit Redux \autocite[branch=\\redux]{repo} anhand der definierten Bewertungskriterien bewertet.
\paragraph{\nameref{sec:changeablility}} Die Änderbarkeit und Skalierbarkeit bei Redux lässt sich anhand verschiedener Aspekte beschreiben.
Ein Problem für die Skalierbarkeit kann der zentrale Zustand werden. Dieser besteht aus einer Klasse, die den gesamten Zustand der App abbilden soll. Bei großen Apps, könnte dieses Konzept an seine Grenzen kommen, besonders, wenn eine Anwendung aus mehreren Modulen besteht.
Die Untersuchung der Verknüpfung mehrere Zustände ist für Redux nicht anwendbar, da hier nur ein zentraler Zustand verwendet wird. Allerdings muss man sagen, dass dies auch zur Folge hat, dass Reducer viele Aufgaben übernehmen müssen, die nicht auf den ersten Blick offensichtlich sind, und aus der fehlenden Möglichkeit resultieren, mehrere Zustände zu haben, die voneinander abhängen.
Um die Reducer besser strukturieren zu können, bietet die Bibliothek, Reducer eines Teilaspektes des Zustands zusammenzufassen, womit diese nur ein Teilaspekt des Zustands tangiert.
Zusammenfassend wird die Skalierbarkeit und Änderbarkeit mit \textquote{nicht erfüllt} bewertet.
\paragraph{\nameref{sec:testability}} Für die Testbarkeit werden zum einen Tests der Geschäftslogik und zum anderen Tests von Widgets, die auf den Store zugreifen bewertet.
Für die Tests der Geschäftslogik ist es ausreichend, den Store manuell zu erstellen und die gewünschte Action zu depeschieren. Anschließend kann anhand des zentralen Zustands geprüft werden, ob das gewünschte Ergebnis eingetreten ist.
Die Tests der Middlewares hingegen stellen sich als schwierig heraus, da hier asynchrone nicht-wartende Aktionen durchgeführt werden, womit es erforderlich wäre, auf die gewünschte Action zu warten, ohne zu wissen, ob diese tatsächlich jemals depeschiert wird.
Der zentrale Zustand sollte selbst keine Geschäftslogik beinhalten und lässt sich somit bei Widget-Tests ohne Probleme durch einen Platzhalter ersetzen.
Aufgrund der Probleme beim Testen der Middlewares, wird die Testbarkeit mit \textquote{teilweise erfüllt} bewertet.
\paragraph{\nameref{sec:efficiency}} Nach der Ausführung der Teststrecke ergaben die Zähler folgendes Ergebnis:
\lstinputlisting[caption={Anzahl der Rendervorgänge bei Redux}]{results/redux/benchmarks.txt}
\paragraph{\nameref{sec:complexity}} Die Auswertung der Metriken (vgl. \autoref{metrics:redux}) ergab eine \ac{mi} von 82 für das gesamte Projekt.
\paragraph{\nameref{sec:readability}} Die Verständlichkeit und Lesbarkeit wird anhand der definierten Aspekte bewertet.
Redux bringt mit dem aus dem React-Ökosystem stammenden Konzept ein völlig neues Konzept in das Flutter-Ökosystem. Begriffe wie Reducer, Action und Middlewares spielen außerhalb von Redux in Flutter sonst nur eine untergeordnete Rolle. Somit müssen Entwickler*innen hier sich vor der Benutzung zuerst mit diesem Konzept beschäftigen, was für die Verständlichkeit nicht dienlich ist.
Auf der anderen Seite bietet Redux mit der klaren Aufteilung in Action, Reducers, Middlewares und State eine klare Struktur und macht den Quelltext aufgrund der relativ kleinen Methoden lesbar. Es mag allerdings bezweifelt werden, ob diese Lesbarkeit bei einem in der Theorie immer weiter wachsenden zentralen Store auf Dauer gewährleistet werden kann, da diese Klasse mit der Anwendung mitwachsen würde.
Das Problem der tiefen Verschachtlung findet bei Redux keine Anwendung, da hier auf einen Zustandsverwaltungsmechanismus außerhalb des Widget-Baums gesetzt wird und der Store lediglich an einer zentralen Stelle in den Widget-Baum injiziert wird.
Die Verständlich und Lesbarkeit wird abschließend mit \textquote{teilweise erfüllt} bewertet.
\paragraph{\nameref{sec:documentation}} Die Dokumentation \autocite{reduxDocs} von Redux beschreibt die grundlegenden Konzepte, sowie verweist für detaillierte Erklärungen auf die Dokumentation von Redux für React. Zudem existieren in der Dokumentation detaillierte Anwendungsbeispiele. Zusätzlich zur offiziellen Dokumentation, gibt es eine große Zahl an Publikationen für Redux für React, die in großen Teilen anwendbar auf die Flutter-Umsetzung von Redux sind.
Die Dokumentierung wird daher mit \textquote{vollständig erfüllt} bewertet.
\paragraph{\nameref{sec:structure}} Redux bestimmt die Struktur der Anwendung klar mit, da durch die feste Aufteilung in die bereits bestehenden Elemente wie Reducer oder Action, eine Struktur sich impliziert.
Technisch wird diese zusätzlich forciert, indem über die Bibliothek geprüft wird, ob beispielsweise die Reducer der geforderten Struktur entsprechen. Zusätzlich kann damit sichergestellt werden, dass Reducer immer ausschließlich synchrone Prozeduren durchführen.
Daher wird die Strukturbestimmung mit \textquote{vollständig erfüllt} bewertet.