unity尧明的博客

Installers  通常，每个子系统都有一些相关的绑定集合，因此将这些绑定组合到一个可重用的对象中是有意义的。在Zenject中，这种可重用的对象被称为 “installer”。你可以按以下方式定义一个新的安装器。public class FooInstaller : MonoInstaller{ public override void InstallBindings() { Container.Bind<Bar>().AsSingle();

简介  请注意，如果你在寻找Zenject的旧文档，你可以在这里找到。Zenject 3.x, Zenject 4.x 和 Zenject 5.x  Zenject是一个轻量级、高性能的依赖注入框架，专门针对Unity 3D（但它也可以在Unity之外使用）。它可以用来把你的应用程序变成一个松散耦合的部分的集合，具有高度细分的责任。然后，Zenject可以将这些部分以多种不同的配置粘合在一起，使你能够以一种可扩展和极其灵活的方式轻松地编写、重用、重构和测试你的代码。在以下平台上用Unity 3D测试：

3.1.2 自动布线（Auto-wiring）  DI容器依靠编译为使用构造器注入的所有类的静态信息而茁壮成长。使用反射，他们可以分析所请求的类并确定需要哪些依赖关系。  一些DI 容器也理解属性注入模式，但是所有的DI 容器本质上都理解构造器注入，并通过将自己的配置与从类的构造器中提取的信息相结合来构成对象图。这就是所谓的自动布线（AUTO-WIRING）。定义： 自动布线是指从抽象和具体类型之间的映射中自动构成一个对象图的能力。  图3.4 描述了大多数DI 容器在自动连接一个对象图时所遵循

3.1 介绍DI 容器  DI 容器是一个软件库，它可以自动处理许多涉及对象组合和管理其寿命的任务。尽管用 "穷人的DI "(POOR MAN’S DI)可以写出所有需要的基础结构代码，但它并没有为一个应用程序增加多少价值。另一方面，组成对象的任务具有一般的性质，可以一劳永逸地解决；这就是所谓的通用子域。注意：穷人的DI 目前已经改名为 pure DI定义: 一个DI 容器是一个提供DI功能的库。注意：DI容器也被称为反转控制（IoC）容器或轻量级容器。  虽然你需要解决应用程序的

DI Containers（DI 容器）菜单XML配制作为配置的代码自动注册组合根注册 解决 释放  当我还是个孩子的时候，我和母亲偶尔会做冰激凌。这并不经常发生，因为这需要大量的工作，而且很难做好。如果你从来没有尝试过制作冰淇淋，图3.1说明了这个过程。  真正的冰淇淋是以奶油为基础的，它是由糖、蛋黄和牛奶或奶油制成的淡奶油冻。如果加热太多，这种混合物会凝固。即使你设法避免这种情况，下一阶段也会出现更多问题。 如果单独留在冰箱里，奶油混合物会结晶，所以你必须定期搅拌，直到它变得如此

2.3 扩充示例应用程序  为了使我们能够更好地理解DI，我需要扩展商业应用的样本。到目前为止，我一直把这个应用保持得尽可能简单和小，以便温和地介绍一些核心概念和原则。因为DI的主要目的之一是管理复杂性，我们需要一个复杂的应用来充分体会它的力量。...

2.2.2 分析松耦合的实现  上一节包含了很多细节，所以如果你一路上失去了对大局的关注，那也就不足为奇了。在本节中，我将尝试用更广泛的术语来解释所发生的事情。相互作用  每一层中的类都以直接或抽象的形式相互作用。它们是跨越模块边界的，所以很难了解它们是如何相互作用的。 图2.20说明了依赖关系是如何被连接的。  当应用程序启动时，Global.asax的代码会创建一个新的自定义控制器工厂。 应用程序保持对控制器工厂的引用，所以当页面请求进来时，应用程序会在工厂上调用CreateController

Menu:对依赖项注入的误解依赖项注入的目的依赖项注入的好处何时应用依赖项注入 您可能已经听说过制作酱汁意大利面酱(sauce béarnaise)很困难。即使是许多经常做饭的人也从未尝试做过。很可惜，因为酱汁很美味（传统上与牛排搭配，但它也很好地搭配白芦笋，荷包蛋和其他菜肴）。可以替代现成的调味料或速溶混合物等替代品，但是这些替代品的满意度不如真实的调味品。 定义 意大利面酱(sauce béarnaise)是一种由蛋黄和黄油制成的乳化酱，用龙蒿、香芹、香葱和醋调味。它不含水。 制

  依赖项注入(DI)是面向对象编程中最容易被误解的概念之一。混乱之处很多，涉及术语、目的和机制。它应该被称为依赖注入、控制反转，甚至是第三方连接吗？依赖注入的目的仅仅是支持单元测试，还是有更广泛的目的？DI是否与服务位置相同？是否需要DI容器？  有很多讨论依赖注入的博客文章、杂志文章、会议演示等等，但不幸的是，它们中的许多使用了相互矛盾的术语或给出了糟糕的建议。这在所有方面都是正确的，即使是像微软这样有影响力的大公司也增加了困惑。  事情不必是这样的。在这本书中，我提出并使用了一个一致的术语，我希望

英文原文：http://yacoubsoftware.blogspot.com/2015/08/why-di-containers-fail-with-complex.html 在面向对象编程中，Solid是一组原则，它允许我们创建灵活的软件，在未来易于维护和扩展。如果我们使用这些原则，我们的代码库中最终会有很多小类。这些类中的每一个都只有一个职责，但可以与其他类协作。 我们使用依赖注入(Dependency Injection)来创建松散耦合的类。类并不直接依赖于其他类，而是依赖于抽象。一个类声

英文原文：https://blog.ploeh.dk/2014/06/10/pure-di/Pure DI是没有DI容器的依赖注入。TL;DR:术语Pure DI取代了术语Poor Man’s DI. 这篇帖子实质上是提出了一种术语的改变。在我关于依赖注入(DI)的书中，我仔细地解释了纯形式的依赖注入的原理和模式，而不涉及依赖注入容器。只有在第4部分中，您才能广泛地了解各种DI容器，即使在这里，您也了解到DI原则和模式是如何映射到各种容器的。 DI是一组原则和模式；DI容器是可选的帮助库。 

英文原文：https://blog.ploeh.dk/2011/07/28/CompositionRoot/ 在我的书（Dependency Injection in .NET）中，我描述了第3章中的根构图模式(Composition Root pattern)。这篇文章是对该模式的总结描述。 在出现后续问题之前，构造器注入模式是很容易理解的：我们应该在哪里组成对象图？ 每个类都应该通过其构造函数要求其依赖项，这很容易理解，但这将组合类及其依赖项的责任推给了第三方。那应该在哪里呢？在我看