CleanArchitectureForAndroid
1.0.0
Dieses Projekt ist eine lose Implementierung von Clean Architecture, wie in meinem Buch Clean Architecture for Android vorgestellt. Es ist ein natives Android -Projekt, das in Kotlin geschrieben wurde. Es zeigt die wichtigsten Prinzipien des Buches und wie sie sich für ein reales Projekt anwenden.
Ich werde mich bemühen, dieses Projekt auf dem neuesten Stand zu halten und es zu nutzen, um die Stärken der Architektur zu demonstrieren: Skalierbarkeit , Testbarkeit und Flexibilität bei der Auswahl von Lösungen von Drittanbietern.
Einfachheit
" Die hier eingeführte Komplexität ist ein Overkill! "
Ich stimme zu. Wenn dies ein endgültiges Projekt sein würde, zu dem jemals keine neue Funktionalität hinzugefügt werden würde, wäre Clean Architecture dafür übermäßig kompliziert gewesen. Die Realität ist jedoch, dass das mobile Projekt selten endgültig ist . Benutzerfeedback, Marketinganforderungen, neue Technologien - Diese und andere Faktoren und andere führen zu kontinuierlichen Änderungen an fast jedem Projekt. Und so wird uns jetzt zu viel Komplexität belohnen, wenn die Zeit für Veränderungen kommt. Dies wird sein, wenn saubere Architektur leuchtet.
Randnotiz: In gewisser Weise habe ich dieses Projekt absichtlich überkompliziert, indem ich verschiedene Technologien eingeführt habe. Das Ziel war es zu zeigen, wie die Architektur auch in realen Szenarien, in denen ein Projekt im Laufe der Zeit gewachsen ist, um mehr als eine technologische Lösung zu enthalten, immer noch funktioniert.
Mapper als Klassen vs. Mapping -Erweiterungsfunktionen
Bei der Zuordnung zwischen Modellen haben wir mehrere Optionen. Die Hauptentscheidung ist zwischen Mapper -Klassen und Kartierungsweiterungsfunktionen.
Während Erweiterungsfunktionen prägnanter sind, beschränkt die Verwendung unserer Auswahlmöglichkeiten für die Testen von Frameworks (Mockito kann beispielsweise die statischen Funktionen nicht stumpfen).
Wie wäre es mit der Injektion der Mapper -Erweiterungsfunktionen? Wir könnten das tun. Dies beseitigt jedoch die Vorteile der Übersichtlichkeit fast ausschließlich. Es erschwert auch die Navigation zur Implementierung.
Und so entschied ich mich für die etwas ausführlicheren konkreten Mapper -Klassen.
Überspringen der Architekturkomponenten von Google
Das größte Problem bei den Architekturkomponenten von Google besteht darin, dass sie Android -Details in die Präsentationsschicht eindringen. Dies verhindert, dass die Präsentationsschicht wirklich agnostisch ist.
Ein weiteres Problem mit den Architekturkomponenten ist, dass sie dem ViewModel zu viel Verantwortung übertragen. Sie lassen es bestehen, dass es nicht besitzt, was zu potenziellen Datensynchronisationsfehlern führt.
Aus diesen Gründen ist dieses Projekt, während er MVVM noch folgt, eher auf Kotlin -Strömen als auf Lebendata an, und implementiert eher reine ViewModels als auf Google.
Verspottungsgerüst
In diesem Projekt werden sowohl Mockito-Kotlin als auch Mockk verwendet, um zu demonstrieren, wie die Verwendung von jedem aussehen würde.
Meine persönliche Präferenz bleibt Mockito-Kotlin . Ich finde den Code leichter zu lesen und zu folgen, wenn ich ihn benutze. Zum Zeitpunkt des Schreibens scheint sich die Branche nach der Anzahl der Sterne in jedem Repository zu Mockk zu beurteilen.
Ich wurde gefragt, ob ich Fälschungen benutze. Ich habe Fälschungen erkundet und festgestellt, dass sie übermäßig ausführlich und zu teuer waren, um sie zu pflegen.
Abhängigkeitsinjektionsrahmen
Ein kritischer Bestandteil der meisten modernen Apps, Abhängigkeitsinjektion (DI), hilft uns, die Objekte zu erhalten, die unsere App erstellen. Es hilft auch, ihren Umfang zu verwalten. Die beliebtesten Entscheidungen in der Android -Welt sind der Angriff (der auf Dolch aufgebaut ist) und Koin.
Der Griff wurde aus zwei Hauptgründen ausgewählt:
XML gegen Jetpack komponieren
Warum nicht beides? Ich habe immer noch viele Bedenken hinsichtlich Jetpack Compose . Trotzdem war es mir wichtig, die vorgestellten Architekturwerke unabhängig vom gewählten UI -Mechanismus gut zu zeigen. Als Übung lade ich Sie ein, die UI -Ebene von komponieren zu XML zu ersetzen oder umgekehrt, ohne die Präsentationsschicht zu aktualisieren.
Saubere Architektur für Android bei Amazon
Clean Architecture im Clean Codierer Blog
Beiträge zu diesem Projekt sind willkommen. Bitte melden Sie Probleme oder Gabel, um Änderungen vorzunehmen und eine Pull -Anfrage zu stellen.
Dieses Projekt wird unter den Bedingungen der MIT -Lizenz verteilt. Weitere Informationen finden Sie unter Lizenz.MD.
