将依赖项注入未打包的对象 - 最佳实践？答案

【问题标题】：Injecting Dependencies into un-Parceled Objects - Best Practices?将依赖项注入未打包的对象 - 最佳实践？
【发布时间】：2016-03-10 21:42:50
【问题描述】：

我有一个域实体——假设它是一个Car——它包含一个我通过 Dagger 注入的存储库实现。当我测试我的实体时，我将存储库换成模拟实现。 Car 和 implements Parcelable。

Dagger 可以在调用 Car(Engine) 时构造对象，但在调用 Car(Parcel) 时显然无法构建对象，因为它是由 Parcelization 框架在内部调用的（通常在从 Intent 获取 Car 时）。

在Car(Parcel) 构造函数中手动注入依赖项是个好主意吗？或者，是否有您可以推荐的最佳实践？在 Parcel 构造函数中注入依赖项肯定会解决我的问题，但建议不要在构造函数中注入依赖项，以保持实例化和注入逻辑之间的关注点分离。

这是我的域实体

public class Car implements Parcelable {

    @Inject ICarRepository CarRepositoryImpl;

    private Engine engine; // User specified engine passed through constructor

    public Car(Engine engine) {
        this.engine = engine;
    }

    public Car(Parcel parcel) {
        this.engine = getEngine(parcel); // Read engine from parcel
        // Inject dependencies here? 
    }

    // Static Parcelable creator and other methods follow...
}

【问题讨论】：

我认为没有人能够回答这个问题。我不知道为什么在模型类中需要CarRepositoryImpl（看起来应该是普通模型？）或者为什么不使用构造函数注入，而是以某种方式在其他地方注入对象。此外，如果每个字段也是可打包的，您可以将对象打包并作为一个整体重新创建。（同样，我认为 parcelable 是/应该只被模型类使用，因此......为什么要依赖？）
这不是模型。它是一个域级实体，代表我的应用程序中的业务逻辑。我需要存储库作为持久层和域（业务逻辑）层之间的接口。

标签： android dependency-injection parcelable dagger-2

【解决方案1】：

David 对您的问题的评论是正确的 - 为什么Car 会依赖于CarRepository？这无疑是一种反模式——存储库用于将实体与建模/持久性分离；在这里，您似乎无缘无故地介绍了一个。但是，让我们假设您只是将存储库放在那里以作为示例。

当然，Dagger 没有自动方法来准备一个对象，一旦它被解包。这意味着，我们必须在某个地方调用 Dagger。

根据我的判断，合适的候选人应该是您的public static final Parcelable.Creator CREATOR，如下所示：

// Creator
public static final Parcelable.Creator<Car> CREATOR 
    = new Parcelable.Creator<>() {
        public Car createFromParcel(Parcel in) {
            Car ret = new Car(in);
            DaggerCarComponent.builder().build().inject(ret);
            return ret;
        }
};

使用此技术实现的目标

您的 Dagger 特定代码不会与构造函数中的实例化逻辑纠缠在一起，而是作为取消打包的特定实现。
您的 Dagger 特定代码是静态的，可以单独测试，而无需通过 Parcel 实例化 Car。
通过使用@Component，您的代码不仅可以抵抗未来的更改（例如添加或删除依赖项），而且还可以抵抗极简/DRY

【讨论】：