时间戳

首页 > 解决方案 > 为什么作者需要在具有 Clean Architecture 的 Domain Layer 中设置依赖注入？

kotlin - 为什么作者需要在具有 Clean Architecture 的 Domain Layer 中设置依赖注入？

问题描述

我正在使用artical学习 Clean Architecture 。

我知道域层是洋葱最内部的部分（不依赖于其他层），它包含实体、用例和存储库接口。

以下代码来自项目https://github.com/lopspower/CleanRxArchitecture

GetListRepo.kt 和 RepoRepository.kt 位于 Domain Layer，可以看图 1

1：我觉得GetListRepo类应该是抽象的还是接口的吧？

2：类的构造函数有3个参数GetListRepo。我不明白作者为什么@Inject要为类的构造函数添加依赖注入。我想我可以GetListRepo在数据布局中以任何方式实例化，为什么作者需要在具有清洁架构的域层中设置依赖注入？

GetListRepo.kt

class GetListRepo
@Inject internal constructor(
    private val repoRepository: RepoRepository,
    useCaseScheduler: UseCaseScheduler? = null, 
    logger: Logger? = null
) : SingleUseCase<List<Repo>, String>(useCaseScheduler, logger) {
   ...

}

RepoRepository.kt

interface RepoRepository {
   val isConnected: Boolean
   ...
}

图 1

在此处输入图像描述

标签： kotlindependency-injectionclean-architecture

解决方案

这类似于您关于接口/抽象类的另一个问题。我会引用自己的话：

使用这样的架构，您可以在未来创建 GetAlbumListUseCase 的替代实现并顺利切换它们。您甚至可以同时使用多个实现，例如不同的对象使用不同的实现 GetAlbumListUseCase。请注意，在您当前的架构中，所有对象都直接依赖于特定的实现，因此切换到另一个需要修改一半的代码。

想象一下你按照你的建议做了，你没有使用依赖注入，但是你GetListRepo在代码中的任何地方都创建了对象。那么在未来您需要有两种提供数据的替代方式，例如使用本地文件和使用远程服务器。想象一下，您需要在应用程序设置中对其进行配置。或者想象一下，您需要创建单元测试，并且提供一个虚假的、测试变体的GetListRepo.

如果你的代码在任何地方都直接实例化，你会怎么做GetListRepo？您将需要修改代码中的许多不同位置，并将一些与加载应用程序设置等相关的逻辑放在任何地方。通过使用依赖注入，所有组件都从外部接收它们的依赖，它们不知道它们是如何被创建的，你可以将你的创建逻辑只放在一个地方。

长话短说：使用 DI 可以让我们解耦应用程序的组件。它使我们的代码更加灵活，适应不同的场景。

推荐阅读