3

在开发和 android 应用程序的上下文中，我应该使用“新”直接在视图中使用演示者，还是将它们注入视图会更好。

不使用注入演示者的优点/缺点：

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

1 回答 1

6

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

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

mPresenter = new Presenter();

假设您正确使用构造函数注入，在创建组件后，您可以节省一些行

@Inject Presenter mPresenter;

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

再次。如果您使用正确的构造函数注入，则很有可能您没有很多模块代码。只需创建一些组件即可。

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

那为什么是匕首？

这是假设您的演示者不依赖其他对象。但如果真的发生了怎么办？

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

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

更？

现在让我们假设您想storage在活动之间从上面共享它。现在，您必须在您的Application或其他可以创建单例的地方添加一些逻辑，以便在整个应用程序中使用。

不过，这可能不是你唯一的单身人士，而且你也会开始把你的东西弄得乱七八糟Application。不要让我开始管理这些对象的生命周期，例如用户登录或注销，确保清除缓存的数据！

再次。匕首实现看起来仍然相同。如果需要更多逻辑，则可以将其很好地放置在模块中，并通过组件依赖项进行抽象。

一旦你开始认为我可以创建处理对象构造和注入的类，你就会知道你一开始就可以使用 dagger ;)

我还写了一篇关于匕首基础知识的博客文章，包括构造函数注入的工作原理，许多初学者由于某种原因没有正确使用。

于 2016-07-13T07:36:27.757 回答