匕首和MVP-主持人应使用匕首进行注射 [英] Dagger and mvp - should presenter use dagger for injection

查看:140
本文介绍了匕首和MVP-主持人应使用匕首进行注射的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我开始在mvp中考虑,演示者中不应该使用匕首.构造匕首的常用方法是使用全局组件,并使用子组件来对图形进行范围界定.通常,此全局组件将在创建appmodule.java类时将applicationContext作为参数.给出应用程序上下文使工作变得更轻松.

I'm starting to think in mvp, dagger should not be used in the presenter. The usual way to construct dagger is using a global component and have subcomponents for scoping the graph. This global component will take an applicationContext as a parameter on creating the appmodule.java class usually. Having the application context given makes life easier.

很好,但是如果我使用全局组件甚至子组件中的模块,则应该传递上下文.因此,这意味着如果我向演示者注入匕首,它将被绑定到applicationContext.这使它很难像junit那样进行测试. Android代码不应出现在presenter中.

That's all fine but if I use a module from the global component or even a subcomponent, the context should be passed in. So that means if I inject the presenter with dagger it will be tied to the applicationContext. THIS MAKES IT DIFFICULT TO TEST as junit. Android code should not be in presenter.

所以我想问的是,仅在活动片段中使用匕首是广播接收者和服务的最佳实践吗?就MVP架构而言.另一个解决方案可能是设计另一个dagger组件,而不是一个与appcomponent或applicationContext不相关的子组件.常见的做法是什么?

So I'm asking is the best practice to just use dagger in activities fragments broadcast receivers and services only? Speaking in terms of mvp architecture that is. The other solution could be to design another dagger component but not a subcomponent that is not related to appcomponent or an applicationContext. What is the common practice?

更新: LETS看一个真实的例子:

UPDATE: LETS look at a real example:

通常,我们会创建一个在应用程序覆盖中关闭的appComponent,如下所示:

usually we'd create a appComponent that's close in application override like this:

public class MyApplication extends Application {

    private AppComponent appComponent;

    @Override
    public void onCreate() {
        super.onCreate();
        appComponent = initDagger(this);
    }

    public AppComponent getAppComponent() {
        return appComponent;
    }

    protected AppComponent initDagger(PomeloApplication application) {
        return DaggerAppComponent.builder()
                .appModule(new AppModule(application))
                .build();
    }}

然后例如在演示者中,我们将在构造函数中执行此操作:

and then for example in the presenter we'd do this in the constructor:

public WelcomePresenter(Context context) {
        super(context);
        presenterComponent = ((MyApplication) context).getAppComponent();
        presenterComponent.inject(this);
    }

所以因为我想要匕首提供者的应用程序上下文,所以我最终迫使调用者依赖于上下文对象.基本上,您无法获得AppComponent模块,直到获得上下文,您才能将其强制转换为"MyApplication"并从组件中注入?所以我在想为什么这种匕首模式使我迫使演示者拥有上下文?

so because I wanted the application Context for dagger providers I ended up forcing callers to depend on a context Object. Basically, you cant get the AppComponent modules until you get a context so you can cast it as "MyApplication" and inject from the component? So i was thinking why is this dagger pattern making me force the presenter to have a context?

即使我们使用了subComponent,它仍然取决于AppComponent,然后在我们的测试案例中,我们必须处理正在创建的应用程序上下文以注入匕首.

Even if we used a subComponent it would still depend on the AppComponent and then in our test case we'd have to deal with an application context being created to get dagger to inject.

因此,我认为应该有一条规则-在MVP中,首选手动构造函数注入而不是匕首注入 因为上课不应该知道如何注入.被注射的东西不应该在乎如何注射.

So I think there should be a rule - in MVP prefer manual constructor injection over dagger injection Because class shouldn’t have knowledge about how it is injected. Something being injected should not care about how it is injected.

dagger.android 概述了我所接受的问题回答.

dagger.android outlines the problem i am talking about as per the accepted answer.

推荐答案

我也同意这样的说法:在演示者中始终没有与android相关的代码总是一个好主意,而dagger不会对此造成干扰."

I also agree with the statement "Not having android related code in your presenter is always a good idea, and dagger does not interfere with that."

首先,我要引起注意的是,从dagger版本2.10开始,您可以使用 dagger.android 软件包,可简化活动和片段中的注入,因此您无需在应用程序中使用MyApplication强制转换.

First, what I want to draw attention that starting from dagger version 2.10 you can use dagger.android package which simplifies injection in the activities and fragments, so you don't need to use MyApplication casting across the app.

第二,为什么不将WelcomePresenter注入活动或片段,反之亦然?

Second, why are you not injecting WelcomePresenter into activity or fragment but vice versa?

这篇关于匕首和MVP-主持人应使用匕首进行注射的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆