bachelor-thesis-flutter-elinux/chapters/05_fallstudie/02_architektur.md

## Architektur

<!-- Flutter Entwicklung folgt einer unidirektionalen
 Datenflussarchitektur, die auf dem Modell-View-Controller
  (MVC)-Muster basiert. -->

Flutter gibt Entwicklern eine große Freiheit bei der
Auswahl der Architektur für ihre Anwendungen. Es gibt
keine festen Regeln oder Vorschriften zur Ordnerstruktur
oder anderen Konventionen bezüglich der Architektur.
Als Architektur für die Demo Anwendung der Fallstudie
wurde eine drei-schichtige Architektur gewählt.
Eine Schichtenarchitektur ist nicht nur Teil der
Architektur von Flutter selbst, sondern ist auch
eine bewährte Architektur für die Entwicklung von
Flutter Anwendungen, sowie auch generell in der Software Entwicklung.
Die drei Schichten der Architektur sind die Präsentationsschicht,
die Geschäftsschicht und die Datenzugriffsschicht.
In der Präsentationsschicht wird die Benutzeroberfläche
mit den Flutter Widgets erstellt. Die Geschäftsschicht
ist für die Implementierung der Geschäftslogik verantwortlich und
die Datenzugriffsschicht für den Zugriff auf die Datenbank
und die Datenverarbeitung [@hajianFlutterEngineering2024, 219].
Die drei Schichten sind voneinander unabhängig und kommunizieren nur
jeweils mit der nächstliegenden Schicht wie in Abbildung \ref{schichten} dargestellt.

\begin{figure}[ht]
\centering
\caption{3-Schichtenarchitektur der Flutter Anwendung}
\label{schichten}
\end{figure}

```{=latex}
\begin{center}
```

```{.mermaid loc=assets/mermaid caption="3-Schichtenarchitektur der Flutter Anwendung" #fig:reference-name}
flowchart TD
    A[Präsentationsschicht] <--> B
    B[Geschäftslogikschicht] <--> C
    C[Datenzugriffsschicht]
```

```{=latex}
\end{center}
```

\begin{figure}[ht]
\centering
\end{figure}

<!-- ### Layers-First Ordnerstruktur

- schneller und einfacher Start
- einfach zu verstehen
- sehr unübersichtlich, sobald die Anwendung wächst
- zusammengehörende Dateien für ein Feature über das Projekt verteilt

### Feature-First Ordnerstruktur

- Dateien, die zu einem Feature gehören, sind an einem
  Ort zu finden
- Layers in Feature
- Einfache Kommunikation
- Verständnis, was ein Feature ist, muss im Team trainiert werden -->

## Ordner Konventionen

Für die 3-Schichtenarchitektur wurde eine
Feature-First Ordnerstruktur gewählt. Die Ordnerstruktur
der fertigen Anwendung ist in Abbildung \ref{ordnerstruktur}
dargestellt.

\begin{figure}[ht]
\caption{Die Ordnerstruktur der Flutter eLinux Anwendung}
\label{ordnerstruktur}
\centering
\begin{minipage}{7cm}
\dirtree{%
.1 lib/.
.2 common.
.2 constants.
.2 features.
.3 benchmark.
.3 home.
.3 material\char`\_demo.
.3 matrix\char`\_rgb.
.3 news\char`\_api.
.3 settings.
.3 system\char`\_resources.
.2 app.dart.
.2 main.dart.
}
\end{minipage}
\end{figure}

Im Hauptverzeichnis der Anwendung befinden sich die Ordner `common`,
`constants`, `features` und die Dateien `app.dart` und `main.dart`.
Der Einstiegspunkt der Anwendung ist die `main.dart` Datei, diese
wird von Dart aufgerufen und startet die `MaterialApp` welche in
der `app.dart` Datei definiert ist. Die `common` und `constants`
Ordner enthalten allgemeine Klassen und Konstanten, die in der
gesamten Anwendung verwendet werden. Der `features` Ordner
enthält die einzelnen Features der Anwendung als Unterordner.
Jedes Feature ist hierbei eines der verschiedenen Fenster,
welches die Demo App besitzt und welche zuvor in den Anforderungen
beschrieben worden sind. Innerhalb jedes Features wird
die 3-Schichtenarchitektur umgesetzt mit den Ordnern `presentation`,
`business` und `data`. Nicht alle Features benötigen dabei alle Schichten,
je nach Komplexität des Features.

Diese Struktur ermöglicht es, dass jedes Fenster der Demo Anwendung
modular und unabhängig von den anderen Fenstern entwickelt wurde
und der Code für ein Feature an einem Ort zu finden ist. Dadurch
wird die Wartbarkeit und Erweiterbarkeit der Anwendung verbessert
und der Code ist leichter zu verstehen.
Für die Demo App ist dies besonders wichtig, da die Anwendung als
Einstiegspunkt so später umstrukturiert werden kann für andere
Anwendungen, die auf der Demo App aufbauen.

## Riverpod

Riverpod ist ein einfaches, aber leistungsstarkes
State-Management-Tool für Flutter. Es wurde entwickelt,
um die Verwaltung des Zustands in Flutter-Anwendungen
zu vereinfachen [@rousseletRrousselGitRiverpod2024]. In dem Projekt wurde
Riverpod genutzt, um die Zustandsverwaltung der Anwendung
zwischen der Prästentations- und Geschäftsschicht zu
verwalten. In der Präsentationsschicht werden die
Provider genutzt, um den Zustand von diesen auszulesen und
in der Geschäftsschicht werden die Provider mithilfe des
Riverpod Generators generiert.
Der Riverpod Generator ist ein Code-Generator, der
mit Riverpod verwendet wird, um die Provider und anderen
Boilerplate-Code automatisch zu generieren. Genutzt wird
der Generator mit der Definition "@riverpod" am Anfang
einer Klasse oder Funktion. Mit dem Paket "_riverpod_annotation_"
werden dabei Hinweise im Code Editor angezeigt, die zeigen,
ob der Code für den Generator korrekt ist oder nicht.
Das Projekt ist so konfiguriert, dass "_riverpod_annotation_"
aktiviert ist. Generierte Dart Dateien enden mit "_.g.dart_".

<!-- eine Klasse pro File, Ausnahmen eng zusammengehörige Klassen
wie zB. Stateful Widgets

state Architektur

android architecture -->

<!-- ### freezed package

generiert den notwendigen Code einer
unveränderlichen Klasse:

- Konstruktor
- toString, equlas, hashCode Methode
- copyWith Methode
- JSON Serialisierung

### State Management

Für das State Management wurde Riverpod gewählt. -->