CleanArchitectureForAndroid
1.0.0
Ce projet est une implémentation lâche de l'architecture propre telle que présentée dans mon livre, Clean Architecture for Android. Il s'agit d'un projet Android natif écrit à Kotlin. Il démontre les principes clés présentés dans le livre et comment ils s'appliquent à un projet de la vie réelle.
Je m'efforcerai de garder ce projet à jour et de l'utiliser pour démontrer les forces de l'architecture: évolutivité , testabilité et flexibilité lorsqu'il s'agit de choisir des solutions tierces.
Simplicité
" La complexité introduite ici est un exagéré! "
Je suis d'accord. S'il devait être un projet final , auquel aucune nouvelle fonctionnalité ne serait ajoutée, alors l'architecture propre aurait été trop compliquée pour cela. Cependant, la réalité est que le projet mobile est rarement définitif. Les commentaires des utilisateurs, les exigences de marketing, les nouvelles technologies - ces facteurs et d'autres conduisent tous à des changements continus à presque tous les projets. Et donc, ce qui peut maintenant sembler trop complexité nous récompensera le moment de changer. Ce sera lorsque l'architecture propre brille.
En guise de note: à certains égards, j'ai intentionnellement trop compliqué ce projet en introduisant différentes technologies. L'objectif était de montrer comment, même dans les scénarios réels, où un projet a peut-être grandi au fil du temps pour inclure plus d'une solution technologique, l'architecture fonctionne toujours.
Les mappeurs comme classes vs fonctions d'extension de cartographie
Lors du cartographie entre les modèles, nous avons plusieurs options. La décision principale est entre les classes de mapper et les fonctions d'extension de cartographie.
Bien que les fonctions d'extension soient plus concises, les utiliser pour la cartographie des limites de nos choix de frameworks de test (Mockito, par exemple, ne peut pas tasser les fonctions statiques).
Que diriez-vous d'injecter les fonctions d'extension du mappeur? Nous pourrions faire ça. Cependant, cela supprime presque entièrement les avantages de la concision. Il rend également plus difficile la navigation vers la mise en œuvre.
Et donc, j'ai opté pour les classes de mapper en béton légèrement plus verbales.
Sauter les composants de l'architecture de Google
Le plus grand problème avec les composants d'architecture de Google est qu'ils divulguent les détails d'Android dans la couche de présentation. Cela empêche la couche de présentation d'être vraiment agnostique de l'interface utilisateur.
Un autre problème avec les composants de l'architecture est qu'ils accordent trop de responsabilité au ViewModel. Ils le font persister à indiquer qu'il ne s'approche pas, conduisant à des bogues potentiels de synchronisation des données.
Pour ces raisons, tout en suivant le MVVM, ce projet repose sur les flux de Kotlin plutôt que sur LiveData , et implémente Pure ViewModels plutôt que sur Google.
Cadre moqueur
Mockito-Kotlin et Mockk sont utilisés dans ce projet pour démontrer à quoi ressemblerait l'utilisation de chacun.
Ma préférence personnelle reste mockito-kotlin . Je trouve le code plus facile à lire et à suivre lorsque vous l'utilisez. Au moment de la rédaction du moment, à en juger par le nombre d'étoiles sur chaque référentiel, l'industrie semble se pencher vers Mockk.
On m'a interrogé sur l'utilisation des contrefaçons . J'ai exploré les contrefaçons et je les ai trouvés trop verbeux et trop chers à entretenir.
Cadre d'injection de dépendance
Une partie critique de la plupart des applications modernes, l'injection de dépendance (DI) nous aide à obtenir les objets qui créent notre application. Cela aide également à gérer leur portée. Les choix les plus populaires dans le monde Android sont HILT (qui est construit sur le dessus de Dagger) et Koin.
Hilt a été choisi pour deux raisons principales:
XML vs jetpack compose
Pourquoi pas les deux? J'ai encore beaucoup de préoccupations concernant la composition de Jetpack . Même ainsi, il était important pour moi de montrer que l'architecture présentée fonctionne bien, quel que soit le mécanisme d'interface utilisateur choisi. En tant qu'exercice, je vous invite à essayer de remplacer la couche d'interface utilisateur de Composer à XML ou vice versa sans mettre à jour la couche de présentation.
Architecture propre pour Android sur Amazon
Architecture propre sur le blog Clean Coder
Les contributions à ce projet sont les bienvenues. N'hésitez pas à signaler tout problème ou fourche pour apporter des modifications et soulever une demande de traction.
Ce projet est distribué en vertu des termes de la licence du MIT. Voir Licence.MD pour plus de détails.
