是“注入一切”吗？ Android中的不良做法？ [英] Is "inject everything" a bad practice in Android?
问题描述
研究依赖项注入时，我发现了一些建议使用注入所有内容，并说 没有必要。
Studying about dependency injection I found some approaches that suggests to inject everything and other saying that it's not necessary to do so.
在我当前的项目中，关于依赖项注入的经验法则是 如果该类是由我创建的，则使它可注入。换句话说，只有诸如 SimpleDateFormat ， ArrayList ， HashMap 之类的类是我项目中的新产品。我这样做的目的是，一旦调用 Injector.getApplicationComponent（）。inject（this） @Inject 活动中的c>。基本上我所有的类都有一个带有 @Inject 的非参数构造函数。
In my current project, my rule of thumb regarding Dependency Injection is "if the class was created by me, I make it injectable". In other words only classes like SimpleDateFormat, ArrayList, HashMap are newables in my project. My intent doing this approach is that I can @Inject any class anywhere once calling Injector.getApplicationComponent().inject(this) in the Activity. Basically all my classes have a non-args constructor with @Inject.
我主要使用DI，因为我认为一旦Dagger生成的类专门使用 new 运算符，它将改善性能和内存使用。但是我从Dagger 1开发人员那里读了一个帖子，说DI不会对性能产生影响，其使用基本上是在减少样板
I was primary using DI because I thought it will improve the performance and memory usage once the new operator is used exclusively by the Dagger generated classes. But I read a post from Dagger 1 developer saying that DI does not have impact on performance and the usage is basically to reduce boilerplate.
第一个问题是：
- Dagger 2没有任何性能优势在Android应用程序中？
我的项目运行正常，我认为尽管有一些缺点，但注入所有内容的方法有助于更好地组织。
My project is running without problems and I think the approach of "inject everything" helps organizing better, despite some drawbacks.
使用此方法的一个示例是以下类：
An example of usage of this approach is the following class:
public class TimelineEntryAdapter {
@Inject
Provider<TwitterEntry> mTwitterProvider;
@Inject
Provider<InstagramEntry> mInstagramProvider;
@Inject
Provider<FacebookEntry> mFacebookProvider;
@Inject
TimelineEntryComparator mComparator;
@Inject
public TimelineEntryAdapter() {
}
第二个问题是：
- 在Android中注入所有内容是否是错误的做法？
如果第二个问题的答案为否，是否有更好的方法来处理非参数构造函数以创建类？因为当我创建带有 @Inject 批注的非参数构造函数且类需要使用一些参数时，我必须使用 setters ：
If the answer for the second question is "No", there is a better way to handle the non-args constructor to create classes? Because when I create an non-args constructor with @Inject annotation and a class need some parameters to work with, I must use setters:
public class SavelArtist {
private MusicBrainzArtist mMusicBrainzArtist;
private DiscogsArtist mDiscogsArtist;
private List<SavelTweet> mTweetList;
private SpotifyArtist mSpotifyArtist;
private List<SavelInstagram> mInstaTimeline;
private List<SavelFacebook> mFacebookTimeline;
private List<SavelRelease> mReleases;
@Inject
Provider<SavelRelease> mReleaseProvider;
@Inject
public SavelArtist() {
}
public void setMusicBrainzArtist(MusicBrainzArtist mbArtist) {
mMusicBrainzArtist = mbArtist;
}
public void setDiscogsArtist(DiscogsArtist discogsArtist) {
mDiscogsArtist = discogsArtist;
}
public void setTweetList(List<SavelTweet> tweetList) {
mTweetList = tweetList;
}
public void setSpotifyArtist(SpotifyArtist spotifyArtist) {
mSpotifyArtist = spotifyArtist;
}
public void setInstaTimeline(List<SavelInstagram> instaTimeline) {
mInstaTimeline = instaTimeline;
}
public void setFacebookTimeline(List<SavelFacebook> fbTimeline) {
mFacebookTimeline = fbTimeline;
}
所有参数均可在构造函数上设置
All the parameters could be set on the constructor, once all are get at the same time in the flow.
推荐答案
研究依赖项注入我发现了一些建议注入的方法
Studying about dependency injection I found some approaches that suggests to inject everything and other saying that it's not necessary to do so.
froger_mcs博客条目您引用的内容并不主张注入所有内容。它很清楚地指出：
The froger_mcs blog entry you quote doesn't advocate injecting everything. It quite clearly states:
这篇文章的目的是展示我们可以做的事情，而不是我们要做的应该这样做。
The purpose of this post is to show what we can do, not what we should do.
它接着指出了注入所有内容的缺点：
And it goes on to state a disadvantage of injecting everything:
如果您想在项目中的几乎所有内容上使用Dagger 2，您将很快看到生成的注入代码使用了64k方法的大块限制。
If you want to use Dagger 2 for almost everything in your project you will quickly see that big piece of 64k methods count limit is used by generated code for injections.
现在，继续您的问题：
Dagger 2在以下方面没有任何性能优势Android应用程序？
Dagger 2 does not any performance advantage in Android application?
虽然Dagger 2提供了其他它没有声称的基于反射的DI框架（例如Guice）的性能优势与通过调用构造函数手动构建对象图相比，可以提供任何性能优势。您可以自己检查生成的类，以确保它们确实最终仍会调用构造函数。
While Dagger 2 offers a performance advantage over other reflection-based DI frameworks (such as Guice) it doesn't claim to offer any performance advantage over manually constructing your object graphs by calling constructors. You can inspect the generated classes yourself to see that these indeed still eventually call constructors.
在Android中注入所有内容是否是一种不好的做法？
Is it a bad practice to inject everything in Android?
让我们采用以下非常常见的Android代码：
Well let's take the following very common Android code:
Intent nextActivity = new Intent(this, NextActivity.class);
startActivity(nextActivity);
我们应该提取一个 IntentFactory 并将其注入使用Dagger 2只是为了避免在这里使用 new 关键字？在这一点上，学步法很容易。 您引用的其他答案中关于可注射剂和可注射剂之间差异的建议更为灵活和优雅。
Should we extract an IntentFactory and inject this using Dagger 2 merely to avoid the new keyword here? At this point, it is easy to approach pedantry. The advice in the other answer you quoted about the difference between injectables and newables is more flexible and elegant.
继续下一个问题：
如果第二个问题的答案为否 ，有没有更好的方法来处理non-args构造函数来创建类？因为当我使用@Inject注释创建一个非参数构造函数并且一个类需要使用一些参数时，我必须使用setter：
If the answer for the second question is "No", there is a better way to handle the non-args constructor to create classes? Because when I create an non-args constructor with @Inject annotation and a class need some parameters to work with, I must use setters:
使用设置器是错误的参数方法。您应该区分依赖项和参数。依赖关系通常与对象本身具有相同的生命周期。在对象的生存期内，可以使用不同的参数调用为该对象公开的方法。
Using setters is the wrong approach for parameters. You should distinguish dependencies and parameters. Dependencies normally have the same lifecycle as the object itself. During the lifetime of the object, the methods exposed for that object may be called with different parameters.
这篇关于是“注入一切”吗？ Android中的不良做法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
