CleanArchitectureForAndroid
1.0.0
该项目是我的书《 Android干净体系结构》中介绍的清洁体系结构的松散实现。这是用Kotlin编写的本地Android项目。它演示了书中介绍的关键原则以及它们如何应用于现实生活项目。
我将努力使该项目保持最新，并使用它来展示体系结构的优势：在选择第三方解决方案时，可伸缩性，可检验性和灵活性。
简单
“这里介绍的复杂性是过度的！ ”
我同意。如果这是一个最终项目，而不会添加任何新功能，那么干净的体系结构将过于复杂。但是，现实是移动项目很少是最终的。用户反馈，营销需求，新技术 - 这些因素和其他因素都导致几乎每个项目的持续更改。因此，现在似乎过多的复杂性可能会奖励我们的变化时间到来。这将是当干净的建筑闪耀时。
附带说明：在某些方面，我通过引入不同的技术来故意过度复杂这个项目。目的是展示即使在现实生活中，一个项目可能会随着时间的推移而增长以包括多个技术解决方案，该建筑仍然有效。
映射器作为类与映射扩展功能
在模型之间映射时，我们有几个选项。主要决策是映射器类和映射扩展功能之间的决定。
虽然扩展功能更简洁，但使用它们来映射限制我们的测试框架的选择（例如，Mockito无法存根静态函数）。
如何注入映射器扩展功能？我们可以做到。但是，这几乎完全消除了简洁的好处。它还使实施变得更加困难。
因此，我选择了更多的详细混凝土映射器类。
跳过Google的架构组件
Google的体系结构组件最大的问题是它们将Android详细信息泄漏到演示层中。这样可以防止演示层真正成为UI不可知论。
架构组件的另一个问题是，它们对ViewModel付出了太多的责任。它们使其持续存在它不拥有的状态，从而导致潜在的数据同步错误。
由于这些原因，在仍在遵循MVVM的同时，该项目依赖于Kotlin流动而不是Livedata ，并实现了纯ViewModels而不是Google。
模拟框架
该项目中都使用了Mockito-Kotlin和Mockk，以演示每个外观的使用方式。
我的个人偏爱仍然是嘲讽 - 凯特林。我发现使用时更容易读取和遵循代码。在写作时，从每个存储库的恒星数量来看，该行业似乎倾向于Mockk。
有人问我使用假货。我已经探索了假货，发现它们过于冗长，太昂贵了。
依赖注入框架
依赖注入（DI）是大多数现代应用程序的关键部分，可帮助我们获取构建应用程序的对象。它还有助于管理他们的范围。在Android世界中，最受欢迎的选择是刀柄（建在匕首之上）和Koin。
选择刀具的主要原因是：
XML与JetPack组成
为什么不呢？我仍然对JetPack组成有很多担忧。即便如此，对于我来说，无论选择哪种UI机制，对我来说都很重要。作为练习，我邀请您尝试将UI层从组合替换为XML，反之亦然，而无需更新演示层。
亚马逊上的Android的清洁体系结构
清洁编码器博客上的清洁架构
欢迎对该项目的贡献。请随时报告任何问题或分叉，以进行更改并提出拉动请求。
该项目根据MIT许可证的条款分发。有关详细信息，请参见License.MD。
