Android 如果你'；你在尝试干净的架构吗？

在《清洁建筑》一书中，罗伯特·马丁说：

在主组件中，依赖项应该由 依赖注入框架。一旦注入主管道，主管道 应该正常分发这些依赖项，而不使用 框架

马丁，罗伯特C。。清洁建筑（罗伯特·C·马丁系列）（p。 232). 培生教育。Kindle版

然而，匕首不是这样工作的。一旦您在应用程序中设置了依赖项，您仍然需要将其作为一个框架来依赖，例如，编写@Inject注释以将依赖项放入类中。没有办法正常地“分发这些依赖项”，我假设他是指通过构造函数传递它们

---

有谁能帮我澄清一下我的理解，以及如何最好地以干净的风格使用Dagger？

在Android上，完全遵循您从Robert Martin那里引用的建议是相当困难的

这是因为没有精确的

main

入口点<代码>应用程序、

服务

和

活动

是准入口点，因为您的应用程序将从实例化其中一个的操作系统开始

但是，在生命周期回调之前，您无法控制构造函数或任何东西。因此，Android上的Dagger 2不得不依赖于手动调用请求组件，并在生命周期回调准入口点内调用

Component\inject（）

然而，已经采取了一些措施来解决这一问题。通过使您依靠
androidjector
而不是对
应用程序的一系列调用来手动检索组件，可以解决这个问题

甚至更进一步，现在有了一个允许控制片段构造器的方法，使得片段适合于构造器注入。如果我们使用这个，那么我们已经在某种程度上遵循了罗伯特·马丁的建议

为了澄清最初的引文，我相信Robert Martin的意思是，除了组件根之外的类不应该被用于获取依赖关系的逻辑所污染（例如，通过进入
应用程序
，拉出Dagger组件）。他并没有禁止使用
@Inject
注释，这是一种轻量级元数据（部分），只是将构造函数标记为要注入的站点

总之，是的-目前在Android上使用Dagger 2的方式并不完全符合Robert Martin的优秀建议。尽管如此，这是一个众所周知的问题，在解决这一问题方面已经取得了一些进展。
谢谢David的精彩回答。我想在用例和实体等高级策略类上使用@Inject，从而将策略绑定到特定的DI框架是不合适的。嗨@xavierdominguez，
@Inject
注释是其中的一部分，因此它们与框架无关。使用它们不会导致你违反罗伯特·马丁纳的建议。谢谢你，大卫。