11.3_使用依赖注入(DI)解耦ViewModel

依赖注入的核心优势

依赖注入（DI）是解耦ViewModel的强大工具，它能让你的代码更灵活、可测试且易于维护。想象一下，你的ViewModel不再直接创建它所依赖的服务，而是通过外部提供这些服务。这就像在餐厅点餐，你不需要自己去厨房做菜，而是由服务员为你送上美味佳肴！ 🍽️

DI的引入，显著提升了代码的可测试性。例如，你可以轻松地用模拟（Mock）服务替换真实服务，从而在单元测试中隔离ViewModel的逻辑。这使得测试变得更加高效和可靠，让你对代码质量充满信心。

为什么ViewModel需要解耦？

ViewModel的职责是处理视图逻辑和数据转换，但它不应该关心如何获取数据或执行网络请求。如果ViewModel直接创建其依赖项，比如一个数据服务，那么它就与这个特定的服务紧密耦合了。这种紧密耦合会带来一系列问题：

• 难以测试：你无法在不初始化整个数据服务栈的情况下测试ViewModel。
• 缺乏灵活性：更换数据源或服务实现会变得非常困难，需要修改ViewModel的内部代码。
• 代码复用性差：ViewModel难以在不同的上下文中使用，因为它被硬编码到特定的依赖项中。

通过解耦，ViewModel变得更加“纯粹”，只专注于其核心职责，从而大大提升了代码的质量和可维护性。

实现依赖注入的策略

在iOS开发中，有几种常见的依赖注入策略可以帮助你解耦ViewModel：

1. 构造器注入 (Constructor Injection)：这是最推荐的方式。在ViewModel的初始化方法中，将所有依赖项作为参数传入。

   class MyViewModel {
       private let dataService: DataServiceProtocol
   
       init(dataService: DataServiceProtocol) {
           self.dataService = dataService
       }
       // ...
   }

   这种方式清晰地表明了ViewModel的所有依赖，并且强制你在创建ViewModel时提供它们。

2. 属性注入 (Property Injection)：通过ViewModel的公共属性来设置依赖项。

   class MyViewModel {
       var dataService: DataServiceProtocol?
       // ...
   }

   虽然这种方式提供了更大的灵活性，但它也可能导致ViewModel在没有完全配置的情况下被使用，增加了潜在的运行时错误。

3. 方法注入 (Method Injection)：在ViewModel的某个方法中传入依赖项。这通常用于特定操作所需的依赖。

选择合适的注入策略取决于你的具体需求和项目架构。构造器注入通常是最佳选择，因为它提供了最强的类型安全和可预测性。

依赖注入的实践案例

让我们看一个具体的例子。假设你有一个UserListViewModel，它需要一个UserService来获取用户数据。

protocol UserServiceProtocol {
    func fetchUsers(completion: @escaping ([String]) -> Void)
}

class RealUserService: UserServiceProtocol {
    func fetchUsers(completion: @escaping ([String]) -> Void) {
        // 模拟网络请求
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
            completion(["Alice", "Bob", "Charlie"])
        }
    }
}

class MockUserService: UserServiceProtocol {
    func fetchUsers(completion: @escaping ([String]) -> Void) {
        completion(["TestUser1", "TestUser2"])
    }
}

class UserListViewModel {
    private let userService: UserServiceProtocol
    var users: [String] = []
    
    init(userService: UserServiceProtocol) {
        self.userService = userService
    }
    
    func loadUsers() {
        userService.fetchUsers { [weak self] fetchedUsers in
            self?.users = fetchedUsers
            // 通知视图更新
        }
    }
}

在你的ViewController中，你可以这样创建UserListViewModel：

// 在生产环境中
let realUserService = RealUserService()
let viewModel = UserListViewModel(userService: realUserService)

// 在测试环境中
let mockUserService = MockUserService()
let testViewModel = UserListViewModel(userService: mockUserService)

通过这种方式，UserListViewModel完全不知道它使用的是RealUserService还是MockUserService，它只依赖于UserServiceProtocol。这种解耦让你的代码变得异常强大和灵活！ 💪

依赖注入容器的引入

当你的项目变得越来越大，依赖项越来越多时，手动管理依赖注入可能会变得繁琐。这时，依赖注入容器（DI Container）就派上用场了。DI容器是一个框架，它可以帮助你自动化依赖项的创建和管理。

流行的Swift DI容器包括Swinject、Resolver等。它们允许你注册服务及其实现，然后在需要时解析这些服务。这大大简化了依赖图的管理，让你的代码库更加整洁和可扩展。使用DI容器，你可以轻松地在不同环境中切换依赖实现，例如在开发环境中使用模拟数据，在生产环境中使用真实数据。这无疑是提升开发效率的利器！ 🚀