领域层需要自己的实体，因此下一步是定义它们. 我们现在有两个实体: User and UserLocation:

数据类User(var id: Int)? = null, val name: String, var isActive: Boolean = false)

数据类UserLocation(var id: Int)? = null, val纬度:双，val经度:双，val时间:长，val userId: Int)

既然我们知道要返回什么数据，就必须声明数据提供程序的接口. These will be IUsersRepository and ILocationsRepository. 它们必须在模型层中实现:

接口IUsersRepository {
    fun setActiveUser(userId: Int): OneOf
    fun getActiveUser(): OneOf
    fun createUser(user: User): OneOf
    fun removeUser(userId: Int): OneOf
    fun editUser(user: User): OneOf
    fun users(): OneOf>
}

接口ILocationsRepository {
    fun locations(userId: Int): OneOf>
    fun addLocation(location: UserLocation): OneOf
}

这组操作应该足以为应用程序提供必要的数据. At this stage, 我们不决定如何存储数据——这是一个我们希望独立的细节. For now, our domain layer doesn’t even know that it’s on Android. 我们会尽量保持这种状态. 我稍后会解释).

最后(或者几乎是最后)一步是为我们的 UseCaseS，它将被表示数据使用. 它们都非常简单(就像我们的应用程序和数据一样简单)——它们的操作仅限于从存储库调用适当的方法, e.g.:

class GetLocations @Inject constructor(private val repository: ILocationsRepository) : UseCase, UserIdParams>() {
    override suspend fun run(params: UserIdParams): OneOf> = repository.locations(params.userId)
}

The Repository 抽象使我们 UseCases 非常容易测试-我们不需要关心网络或数据库. 它可以被以任何方式嘲笑, so our unit tests will test actual use cases and not other, unrelated classes. 这将使我们的单元测试简单而快速:

@RunWith (MockitoJUnitRunner::类)
类GetLocationsTests {
    private lateinit var getLocations: getLocations
    private val locations = listOf(UserLocation(1,1 .).0, 1.0, 1L, 1))

    @Mock
    private lateinit var locationsRepository: ILocationsRepository

    @Before
    fun setUp() {
        getLocations = getLocations (locationsRepository)
    }

    @Test
    fun '应该调用getLocations locations ' () {
        runBlocking {getLocations.运行(UserIdParams (1)}
        验证(locationsRepository,乘以(1)).locations(1)
    }

    @Test
    fun '应该返回从locationsRepository获取的位置' (){
        给定{locationsRepository.locations(1) }.willReturn(OneOf.Success(locations))
        val returnedLocations = runBlocking {getLocations.运行(UserIdParams (1)}
        返回位置应该等于其中之一.Success(locations)
    }
}

现在，域层已经完成.

Model

作为Android开发人员，您可能会选择Room，这是用于存储数据的新Android库. 但是，让我们想象一下，项目经理问您是否可以推迟关于数据库的决定，因为管理层正试图在Room和Room之间做出决定, Realm, and some new, 超高速存储库. 我们需要一些数据来开始使用UI，所以我们现在只把它保存在内存中:

类MemoryLocationsRepository @Inject构造器():ILocationsRepository {
    private val locations = mutableListOf()

    override fun locations(userId: Int): OneOf> = OneOf.Success(locations.filter { it.userId == userId })

    override fun addLocation(location: UserLocation): OneOf {
        val addedLocation =位置.copy(id = locations.size + 1)
        locations.add(addedLocation)
        return OneOf.成功(addedLocation)
    }
}

Presentation

两年前，我写了一篇 article about MVP as a very good app structure for Android. When Google announced the great Architecture Components, which made Android应用程序 development far easier, MVP is no longer needed and can be replaced by MVVM; however, 这种模式中的一些想法仍然非常有用，比如关于哑视图的想法. 它们应该只关心显示数据. To achieve this, we will make use of ViewModel and LiveData.

我们的应用程序的设计是非常简单的一个活动与底部导航, 其中两个菜单项显示 locations fragment or the users fragment. In these views we use ViewModels, which in turn use UseCaseS从域层，保持通信整洁和简单. 例如，这里是 LocationsViewModel:

类LocationsViewModel @Inject构造函数(private val getLocations: getLocations，
                                             private val saveLocation: SaveLocation) : BaseViewModel() {
    var locations = MutableLiveData>()

    loadLocations(userId: Int) {
        getLocations.执行(UserIdParams(userId)){它.oneOf(::handleError，::handleLocationsChange)}
    }

    fun saveLocation(location: UserLocation, onSaved: (UserLocation) -> Unit) {
        saveLocation.执行(UserLocationParams(位置)){
            it.oneOf(::handleError) { location -> handleLocationSave(location, onSaved) }
        }
    }

    private fun handleLocationSave(location: UserLocation, onSaved: (UserLocation) -> Unit) {
        val currentLocations =位置.value?.toMutableList() ?: mutableListOf()
        currentLocations.add(location)
        this.locations.value = currentLocations
        onSaved(location)
    }

    private fun handleLocationsChange(locations: List) {
        this.locations.value = locations
    }
}

对那些不熟悉viewmodels的人做一点解释—我们的数据存储在位置变量中. 当我们从 getLocations 用例时，它们被传递给 LiveData value. 此更改将通知观察者，以便他们可以做出反应并更新他们的数据. 我们为片段中的数据添加了一个观察者:

类LocationsFragment: BaseFragment() {

...

    initLocationsViewModel() {
       locationsViewModel = ViewModelProviders.of(activity!!viewModelFactory) [LocationsViewModel::类.java]
       locationsViewModel.locations.observe(this, Observer> { showLocations(it ?: emptyList()) })
       locationsViewModel.error.observe(this, Observer { handleError(it) })
    }

    private fun showLocations(locations: List) {
        locationsAdapter.地点=地点
    }

    私有fun handleError(错误:失败?) {
        toast(R.string.user_fetch_error).show()
    }

}

每次位置变化, 我们只是将新数据传递给分配给回收视图的适配器——这就是在回收视图中显示数据的正常Android流程.

因为我们在视图中使用ViewModel, 它们的行为也很容易测试——我们可以只模拟ViewModels而不关心数据源, network, or other factors:

@RunWith (RobolectricTestRunner::类)
@Config(application = TestRegistryRobolectricApplication::class)
类LocationsFragmentTests {

    private var usersViewModel = mock(UsersViewModel::class.java)
    private var locationsViewModel = mock(LocationsViewModel::class.java)

    lateinit var fragment: LocationsFragment

    @Before
    fun setUp() {
        UsersViewModelMock.intializeMock (usersViewModel)
        LocationsViewModelMock.intializeMock (locationsViewModel)

        fragment = LocationsFragment()
        fragment.viewModelFactory = ViewModelUtils.createFactoryForViewModels(usersViewModel, locationsViewModel)
        startFragment(片段)
    }


    @Test
    “getActiveUser on start”(){
        Mockito.验证(usersViewModel).getActiveUser()
    }

    @Test
    Fun '应该从活跃用户加载位置' (){
        usersViewModel.activeUserId.value = 1
        Mockito.验证(locationsViewModel).loadLocations(1)
    }

    @Test
    Fun '应该显示位置' (){
        val date =日期(1362919080000)//10-03-2013 13:38

        locationsViewModel.locations.value = listOf(UserLocation(1,1 .).0, 2.0, date.time, 1))

        val recyclerView = fragment.find(R.id.locationsRecyclerView)
        recyclerView.measure(100, 100)
        recyclerView.布局(0,0,100,100)
        val adapter = recyclerView.适配器作为LocationsListAdapter
        adapter.itemCount应该是1
        val viewHolder = recyclerView.findViewHolderForAdapterPosition(0) as LocationsListAdapter.LocationViewHolder
        viewHolder.latitude.文本“应该等于”“迟:1”.0"
        viewHolder.longitude.文本'应该等于' "Lng: 2.0"
        viewHolder.locationDate.文本'应该等于' "10-03-2013 13:38"
    }
}

您可能会注意到，表示层也被划分为具有清晰边界的较小层. Views like activities, fragments, ViewHolders, etc. 只负责显示数据. 它们只知道ViewModel层，并且只使用ViewModel层来获取或发送用户和位置. It is a ViewModel which communicates with the domain. ViewModel实现对于视图和useccase对于域是一样的. 换句话说，干净的架构就像一个洋葱——它有层，层也可以有层.

依赖注入

We have created all the classes for our architecture, 但还有一件事要做——我们需要一些东西把所有东西连接在一起. The presentation, domain, 模型层保持干净, 但我们需要一个模块，它将是最脏的一个，它将通过这些知识了解所有的事情, 它可以连接我们的图层. 实现它的最佳方法是使用一种常见的设计模式(SOLID中定义的干净代码原则之一)——依赖注入, 它为我们创建合适的对象，并将它们注入所需的依赖. 我在这里使用了Dagger 2(在项目中期，我将版本更改为2).16，它有更少的样板)，但你可以使用任何你喜欢的机制. 最近，我玩了一下Koin库，我觉得它也值得一试. 我想在这里使用它，但是在测试时，我有很多嘲弄ViewModels的问题. 我希望我能尽快找到解决问题的办法——如果可以的话, 我可以在使用Koin和Dagger 2时展示这个应用程序的不同之处.

你可以在GitHub上用标签architecture_v1检查这个阶段的应用程序.

Changes

We finished our layers, tested the app—everything is working! 除了一件事——我们仍然需要知道我们的PM想要使用什么数据库. 假设他们来找你说管理层同意使用房间, but they still want to have a possibility to use the newest, 未来的超高速库, 所以你需要时刻牢记潜在的变化. Also, 其中一个利益相关者询问是否可以将数据存储在云中，并想知道这种更改的成本. So, 现在是时候检查我们的架构是否良好，以及我们是否可以在不改变表示层或域层的情况下更改数据存储系统.

Change 1

使用Room的第一件事是为数据库定义实体. 我们已经有了一些: User and UserLocation. 我们要做的就是添加注释，比如 @Entity and @PrimaryKey, and then we can use it in our model layer with a database. Great! 这是打破我们想要保持的所有架构规则的好方法. 实际上，域实体不能通过这种方式转换为数据库实体. 想象一下，我们也想从网络上下载数据. 我们可以使用更多的类来处理网络响应——转换我们的简单实体，使它们与数据库和网络一起工作. 这是通往未来灾难的最短路径(并哭喊:“到底是谁写的这段代码?”). 我们需要为我们使用的每种数据存储类型单独的实体类. 它不会花费太多，所以让我们正确地定义Room实体:

@Entity
数据类UserEntity(
        @PrimaryKey(autoGenerate = true) var id: Long?,
        @ColumnInfo(name = "name") var name: String，
        @ColumnInfo(name = "isActive") var isActive: Boolean = false
)

@Entity(foreignKeys = [
    ForeignKey(entity = UserEntity::class)
            parentColumns = ["id"]，
            childColumns = ["userId"]，
            onDelete = CASCADE)
])
数据类UserLocationEntity(
    @PrimaryKey(autoGenerate = true) var id: Long?,
    @ColumnInfo(name = "latitude") var latitude: Double,
    @ColumnInfo(name = "longitude") var longitude: Double,
    @ColumnInfo(name = "time") var时间:长，
    @ColumnInfo(name = "userId") var userId: Long
)

As you can see, 它们几乎与领域实体相同, 所以合并它们是很有诱惑力的. 这只是一个意外——数据越复杂，相似度就越小.

接下来，我们必须实现 UserDAO and the UserLocationsDAO, our AppDatabase的实现 IUsersRepository and ILocationsRepository. 这里有个小问题ILocationsRepository should return a UserLocation, but it receives a UserLocationEntity from the database. The same is for User-related classes. 在相反的方向，我们经过 UserLocation 当数据库需要 UserLocationEntity. 要解决这个问题，我们需要 Mappers 在我们的域和数据实体之间. I used one of my favorite Kotlin features—extensions. 我创建了一个名为 Mapper.kt, 并将所有用于类之间映射的方法放在那里(当然, it’s in the model layer—the domain doesn’t need it):

fun User.toEntity() = UserEntity(id .?.toLong()， name, isActive)
fun UserEntity.toUser() = User(this ..id?.toInt()， name, isActive)
fun UserLocation.toEntity() = UserLocationEntity(id .?.toLong()，纬度，经度，时间，userId.toLong())
乐趣UserLocationEntity.toUserLocation() = UserLocation(id .?.toInt()，纬度，经度，时间，userId.toInt())

The little lie I mentioned before is about domain entities. 我写道，他们对Android一无所知，但这并不完全正确. I added @Parcelize annotation to the User entity and extend Parcelable there, making it possible to pass the entity to a fragment. 对于更复杂的结构, we should provide the view layer’s own data classes, and create mappers like between domain and data models. Adding Parcelable 我敢冒的一个小风险，我知道，如果有的话 User 我将为表示创建单独的数据类并将其删除 Parcelable 从领域层.

最后要做的是修改我们的依赖注入模块，以提供新创建的依赖注入 Repository 实现，而不是之前的 MemoryRepository. 在我们构建并运行应用程序之后，我们可以去PM显示带有房间数据库的工作应用程序. 我们也可以通知PM，增加网络不会花费太多时间, and that we are open to any storage library the management wants. 您可以检查哪些文件被更改了—只更改了模型层中的文件. 我们的建筑非常整洁! Every next storage type can be built in the same way, 只需扩展我们的存储库并提供适当的实现. 当然，我们也可能需要多个数据源，比如数据库和网络. What then? Nothing to it, 我们只需要创建三个存储库实现—一个用于网络, 一个用于数据库, and a main one, where the correct data source would be selected (e.g.(如果我们有网络，从网络加载，如果没有，从数据库加载).

你可以在GitHub上用标签architecture_v2查看这个阶段的应用程序.

So, 一天快结束了——你坐在电脑前，端着一杯咖啡, 该应用程序已准备好发送到Google Play, 突然，项目经理来问你:“你能添加一个功能，可以从GPS中保存用户的当前位置吗??”

Change 2

一切都在变，尤其是软件. This is why we need clean code and clean architecture. 然而，如果我们不假思索地编码，即使是最干净的东西也可能是脏的. 实现从GPS获取位置时的第一个想法是在活动中添加所有位置感知代码, run it in our SaveLocationDialogFragment and create a new UserLocation 有相应的数据. 这可能是最快的方法. 但是，如果我们疯狂的PM来找我们，要求我们将获取位置从GPS更改为其他提供商(例如GPS)，该怎么办.g.比如蓝牙或网络)? 这些变化很快就会失去控制. 我们怎样才能干净利落地做到这一点呢?

用户位置是数据. 获取位置是 UseCase-所以我认为我们的领域和模型层也应该涉及到这里. 这样，我们就多了一个 UseCase to implement—GetCurrentLocation. We also need something that will provide a location for us—an ILocationProvider 接口，使 UseCase 独立于GPS传感器等细节:

接口ILocationProvider {
    fun getLocation(): OneOf
    fun cancel()    
}

class GetCurrentLocation @Inject constructor(private val locationProvider: ILocationProvider) : UseCase() {
    override suspend fun run(params: NoParams): OneOf =
            locationProvider.getLocation()

    重载fun cancel() {
        super.cancel()
        locationProvider.cancel()
    }
}

You can see that we have one additional method here—cancel. This is because we need a way to cancel GPS location updates. Our Provider implementation, defined in the model layer, goes here:

类GPSLocationProvider构造函数(var activity: activity): ILocationProvider {

    private var locationManager: locationManager? = null
    private var locationListener: GPSLocationListener? = null

    override fun getLocation(): OneOf = runBlocking {
        val grantedResult = getLocationPermissions()

        if (grantedResult.isError) {
            val error = (granteresult =.Error).error
            OneOf.Error(error)
        } else {
            getLocationFromGPS ()
        }
    }

    private suspend fun getLocationPermissions(): OneOf = suspendCoroutine {
        Dexter.withActivity(活动)
                .withPermission(清单.permission.ACCESS_FINE_LOCATION)
                .withListener (PermissionsCallback (it))
                .check()
    }

    private suspend fun getLocationFromGPS (): OneOf = suspendCoroutine {
        locationListener?.unsubscribe()
        locationManager =活动.getSystemService(上下文.LOCATION_SERVICE)作为LocationManager
        locationManager?.let { manager ->
            locationListener = GPSLocationListener(manager, it)
            launch(UI) {
                manager.requestLocationUpdates (LocationManager.Network_provider, 01,0.0 f, locationListener)
            }
        }
    }

    重载fun cancel() {
        locationListener?.unsubscribe()
        locationListener = null
        locationManager = null
    }
}

This provider is prepared to work with Kotlin coroutines. 如果你还记得的话 UseCaseS的run方法是在后台线程上调用的，所以我们必须确保正确地标记我们的线程. As you can see, 我们必须在这里传递一个活动——当我们不再需要侦听器时，从它们取消更新和注销是至关重要的，以避免内存泄漏. 因为它实现了 ILocationProvider, we can easily modify it in the future to some other provider. 我们还可以很容易地测试当前位置的处理(自动或手动), 即使没有启用手机中的GPS，我们所要做的就是替换这个实现，返回一个随机构建的位置. To make it work, we have to add the newly created UseCase to the LocationsViewModel. ViewModel，反过来，必须有一个新方法， getCurrentLocation，它将实际调用用例. 只需要对UI进行一些小的更改，就可以调用它并在dagger中注册GPSProvider——瞧, 我们的应用程序完成了!

Summary

我试图向你展示我们如何开发一个易于维护的安卓应用程序, test, and change. 如果有新人加入你的工作，它也应该很容易理解, 他们在理解数据流或结构方面应该没有问题. 如果他们知道架构是干净的, 他们可以确保UI的更改不会影响模型中的任何内容, and adding a new feature will not take more than predicted. 但这并不是旅程的终点. 即使我们有一个结构良好的应用程序, 它很容易被混乱的代码更改破坏，“只是一会儿”, just to work.“记住——目前还没有代码”.“每个违反我们规则的代码都可以保存在代码库中，并可能成为未来的来源, bigger breaks. 如果你在一周后看到这些代码, 看起来像是有人在代码中实现了一些强依赖, to resolve it, you’ll have to dig through many other parts of the app. 良好的代码体系结构不仅在项目开始时是一个挑战，而且在Android应用程序生命周期的任何阶段都是一个挑战. 每次有东西要改变时，都应该考虑并检查代码. 为了记住这一点，你可以，例如，打印并悬挂你的Android架构图. 你也可以通过把层分成三个Gradle模块来强制层的独立性, 域模块不知道其他模块，表示模块和模型模块不相互使用. 但即便如此，我们还是意识到，应用程序代码中的混乱会在我们最意想不到的时候报复我们.