android - 应该将演示者(mvP)注入(inject)(dagger2)到android中的 View 吗？

Question

在开发和 Android 应用程序的上下文中，我应该直接在使用“new”的 View 中使用 Presenter，还是将它们注入(inject)到 View 中会更好。

不使用注入(inject)演示者的优点/缺点:

1. 开发速度更快，无需编写组件和模块。
2. 演示者与 View 紧密耦合，我认为这不是什么大问题，因为大多数时候演示者不会跨多个 View 共享(即演示者的一个 View )。
3. 可能是测试的问题，因为可以提供演示者的依赖注入(inject)模拟实现(不确定这是否有用，需要对此有更多了解)。

Answer 1

你是对的。从长远来看，使用注入(inject)只会对您有所帮助。您可以花 5 分钟设置您的模块/组件，也可以只是编码。

只要你不做适当的测试，没有太大的区别，如果你的演示者看起来像下面这样

mPresenter = new Presenter();

假设你正确地使用构造函数注入(inject)，在创建你的组件之后，你可以节省一些行来比较

@Inject Presenter mPresenter;

// onCreate or some other place
{
    getComponent().inject(this); /* getComponent() also 4-5 lines */
}

再次。如果您使用适当的构造函数注入(inject)，那么您很可能没有很多模块代码。只需创建一些组件即可。

但是您节省了一些时间，一旦您想进行测试，这只是一些简单的重构，可以很快完成。

为什么选择 Dagger？

这是假设您的演示者不依赖于其他对象。但如果是这样呢？

SharedPreferences preferences = getPreferences();
MyStorage storage = new MyStorage(preferences);
mPresenter = new Presenter(storage);

使用某些东西来存储您的数据是一个很好的用例。虽然您只是在 Activity 中添加了更多关于对象创建的逻辑，但 Dagger 实现看起来还是一样的。

甚至更多？

现在假设您要在 Activity 之间共享上面的存储。现在您必须向您的 Application 添加一些逻辑，或者在您可以创建 Singleton 以在整个应用程序中使用的其他地方添加一些逻辑。

不过，这可能不是您唯一的单例，您也会开始弄乱您的 Application。不要让我开始管理这些对象的生命周期，例如用户登录或注销，请务必清除缓存数据!

再次。 Dagger 的实现看起来还是一样的。如果需要更多逻辑，可以将其很好地放置在模块中并使用组件依赖项进行抽象。

---

一旦您开始思考我可以只创建处理对象构造和注入(inject)的类您就知道您可以首先使用 dagger ;)

我还写了一篇关于 dagger basics 的博文包括构造函数注入(inject)的工作原理，许多初学者出于某种原因没有正确使用它。