141 lines
4.4 KiB
Markdown
141 lines
4.4 KiB
Markdown
## 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.
|
|
|
|
<!-- 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. -->
|