|
28.04.2026 09:25 Uhr |
Nach einer Einführung in das Framework Crux geht es im dritten und letzten Teil der Artikelreihe nun um fortgeschrittene Konzepte und die praktische Integration in realen Anwendungen. Die folgenden Punkte zu fachlichen Typen, Aufteilung in mehrere Apps und dem Einsatz in konkreten Shell-Technologien zeigen einen detaillierten Blick aus der Praxis.
In langlebigen Softwareprojekten ist es ratsam, fachliche Typen unabhängig vom eingesetzten Framework zu definieren. Im Rahmen der in den vorherigen Teilen gezeigten E-Mail-App bietet sich zum Beispiel der Typ EmailAddress an: Dieser Typ kapselt die Validierung und Repräsentation einer E-Mail-Adresse und stellt sicher, dass nur gültige Werte im System verwendet werden. Die Logik zur Prüfung – etwa auf das Vorhandensein des Zeichens @ – ist direkt im Typ verankert und nicht Teil der Crux-App.
Dadurch bleibt die fachliche Logik klar von technischen Details getrennt. Sie kann unabhängig von Crux, anderen Frameworks oder der konkreten Plattform getestet, wiederverwendet und weiterentwickelt werden. Sollte sich die technische Umgebung ändern, bleibt die Kernlogik erhalten und muss nicht neu geschrieben werden.
Fachliche Typen wie EmailAddress erhöhen die Wartbarkeit und Verständlichkeit des Codes und schützen vor Fehlern, indem sie ungültige Zustände bereits beim Erstellen verhindern.
Listing 1: Fachlicher Typ EmailAddress
Fachliche Typen wie EmailAddress lassen sich unabhängig vom Framework testen.
Listing 2: Tests für EmailAddress
Der erste Test prüft, dass eine gültige E-Mail-Adresse akzeptiert und korrekt gespeichert wird. Der zweite Test stellt sicher, dass eine ungültige E-Mail-Adresse (ohne @) abgelehnt und der passende Fehler (MissingAt) zurückgegeben wird.
Wächst das Entwicklungsteam der App, kann es sinnvoll sein, das Team und auch die Anwendung in mehrere eigenständige Apps und Crates aufzuteilen. Ein Kontaktmanagement könnte die bisherige E-Mail-App erweitern und alle eingehenden Kontaktdaten speichern, aktualisieren oder löschen. Dabei bekommt das Kontaktmanagement eine eigene Crux-App, verwaltet in einem separaten Crate. Dieses separate Crate beinhaltet ein abgegrenztes Feature und wird auch als Feature-Crate bezeichnet. Jedes Feature-Crate definiert dabei seine eigenen Events, Models, ViewModels und Effekte – das Model ist also explizit Teil des jeweiligen Features. Die Haupt-App integriert die einzelnen Feature-Crates und koordiniert deren Zusammenspiel.
Listing 3: contacts (Feature-Crate)
Das E-Mail-Feature übernimmt die Funktion der bisherigen E-Mail-App:
Listing 4: email (Feature-Crate)
Die Haupt-App aggregiert die Feature-Modelle und koordiniert die Kommunikation:
Listing 5: Haupt-App-Integration (App-Crate)
Durch diese Aufteilung bleibt die Anwendung modular, testbar und erweiterbar. Jedes Feature verwaltet seinen eigenen Zustand und lässt sich unabhängig entwickeln, testen und warten. Die Haupt-App sorgt für die Orchestrierung und das Zusammenführen der einzelnen ViewModels zu einer konsistenten Oberfläche. So entsteht eine skalierbare Architektur.