除了测试，为什么我们需要Dagger 2？ [英] Beside testing, why do we need Dagger 2?

问题描述

此时，我对依赖注入（DI）的理解仅来自这篇文章。我有兴趣尝试，但我只需澄清一些事情：

At this point, my understanding of Dependency Injection (DI) is only from this article. I'm interested to try, but I just need to clarify some things:

1. 许多人将DI作为减少样板代码的工具。但根据该教程，Dagger 2的设置往往会为配置（模块和组件）创建更多类。我没有尝试过，但从它的外观来看，它并没有减少代码，它只是拆分它们，所以主类看起来更整洁。我错了吗？


2. 尽管 Dagger 2的索赔 DI不仅仅用于测试，许多人主要用于测试，包括 Android自己的指南。你有没有在生产就绪的应用程序中使用Dagger 2？它对您有多大用处？


3. 如果我对通过构造函数创建的传统依赖项非常熟悉，我是否还需要查看Dagger 2？我觉得这个库可能有能力改变我对RxJava的编码方式，我只是不确定它的好处和RxJava给我的一样多。

1. Many refer DI as a tool to reduce boilerplate code. But according to that tutorial, the setup of Dagger 2 tends to create even more classes for configuration (module and component). I have not tried it, but by the looks of it, it isn't reducing the code, it is just splitting them so the main class can look tidier. Am I wrong on this one?
2. Despite Dagger 2's claim that DI isn't just for testing, many are regarding its usage mainly for testing, including Android's own guide. Have you used Dagger 2 in production-ready app? How useful has it been to you?
3. If I am perfectly comfortable with traditional dependency creation via constructor and such, should I still need to look at Dagger 2? I feel like this library might have the power to change how I code the way RxJava does, I'm just not sure the benefit of it is as much as RxJava gave me.

我知道，将Dagger与RxJava进行比较就像将苹果与橙色进行比较。但从某种意义上说，它们都像Dagger一样是水果，而RxJava是可能使我的项目更大的第三方库。

I know, comparing Dagger to RxJava is like comparing apple to orange. But in a sense, they are both a fruit just like Dagger and RxJava are third-party libraries that might make my project larger.

推荐答案

你结合了两个单独的问题，应该分开评估：为什么我们需要依赖注入？和为什么我们需要Dagger 2？

You've combined two separate questions, which should be evaluated separately: "Why do we need dependency injection?" and "why do we need Dagger 2?"

依赖注入（控制反转）非常有用，因为它允许组件的使用者提供组件的依赖关系。以日志格式化程序为例：如果没有依赖注入，您可能需要编写三个不同版本的类，这些版本可以记录到 stdout ，远程服务器或文本文件。相比之下，如果您要写一个 LogFormatter 接受它写入的 Writer ，那么你可以写它一次并传入任何 Writer 是最合适的，包括测试double（你制作的FakeWriter，或StringWriter，或模拟框架创建的mockWriter实例）进行测试。虽然它是为Guice而不是Dagger编写的，但我写了一篇单独的SO答案，讨论了依赖注入在生产使用中的价值还有测试案例;您看到的大多数教程都会关注测试，假设生产和测试是您事先了解的两种情况，其他重用和再利用的机会将在以后出现。

Dependency injection (inversion of control) is useful because it allows the consumer of your component to provide your component's dependencies. Take a log formatter, for example: Without dependency injection you might need to write three different versions of your class that log to stdout, a remote server, or a text file. By comparison, if you were to write a LogFormatter that accepts a Writer to which it writes, then you could write it once and pass in whichever Writer is most appropriate, including a test double (a FakeWriter you make, or a StringWriter, or a mock-framework-created mockWriter instance) for testing. Though it's written for Guice instead of Dagger, I wrote a separate SO answer that talks about the value of dependency injection in production usage and also test cases; most of the tutorials you see will focus on tests under the presumption that "production" and "test" are the two cases you know about up front, where other opportunities for reuse and repurposing will present themselves later.

一旦你接受了依赖注入为你提供的模块化，可重用性和可测试性优势，你可能会留下一个问题：如何管理这些极长的构造函数？毕竟，为了继续 LogFormatter 示例，如果不关心日志的去向，你将无法编写你的应用程序。

Once you embrace the modularity, reusability, and testability benefits that dependency injection provides you, you'll probably be left with one question: How do I manage these enormously-long constructors? After all, to carry forward the LogFormatter example, you wouldn't be able to write your Application without caring where the logs go to.

MyApplication application = new MyApplication(
    new LoggingService(new LogFormatter(new StdOutWriter())),
    new DatabaseService(new MyApplicationDatabase(new File("my.db"))),
    ...);

这就是Dagger的亮点：它可以让您在自动管理构造函数的同时获得依赖注入的所有好处为了你。这使得它可以封装创建对象的责任并使其更清晰，更安全，RxJava可以封装管理和传播异步事件的责任，使其更清洁，更安全。

This is where Dagger shines: It lets you have all the benefits of dependency injection while automatically managing the constructors for you. This allows it to encapsulate the responsibility of creating objects and make it cleaner and safer, the way that RxJava can encapsulate the responsibility of managing and propagating asynchronous events and make it cleaner and safer.

重要的是要意识到Dagger 2的样板减少与手动依赖注入相比，而不是你要比较的原始构造函数调用。如果你坚持直接调用 new ，你可能会完全避免使用这个对象构建样板，但你也会发现自己正在经历困难的杂技试图破坏工作向多个开发人员或尝试测试或重用您编写的代码。集体的痛苦是为什么依赖注入如此受欢迎的概念，以及为什么像Spring，Guice和Dagger这样的图书馆越来越受欢迎。

It's important to realize that Dagger 2's reduction in boilerplate is in comparison to manual dependency injection, not the raw constructor invocations that you're comparing to. If you stick with calling new directly, you'll probably avoid much of this object construction boilerplate entirely, but you'll also find yourself going through difficult acrobatics trying to shard the work out to multiple developers or trying to test or reuse the code you've written. The collective pain is why dependency injection is so popular of a concept, and why libraries like Spring, Guice, and Dagger are gaining popularity.

我可以保证使用Dagger 2在几个特别大，知名且使用良好的Android应用程序中生产。 ：）

I can vouch for the use of Dagger 2 in several particularly large, well-known, and well-used production Android applications. :)

这篇关于除了测试，为什么我们需要Dagger 2？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！