我已经阅读了很多关于依赖注入、控制反转和 IoC 容器的内容。我还主要使用动态语言（工作中的 PHP，家庭中的 Python）进行编程。这是我正在寻找的东西，但是当我把它们拼凑在一起时，这给我留下了很多空白：
所以我正在阅读的是：IoC 容器在静态语言中的作用要大得多，因为在动态语言中执行 DI 要容易得多。但它们也提供了远远超出 DI 的好处，例如为您管理依赖项并让您不必手动将十几个对象串在一起。而且，顺便说一句，它们很复杂，所以不要尝试自己做（但对于 PHP 来说没有好的方法）。
我觉得这些信息让我有点……卡住了。我该怎么办？我在一个非常大的代码库中工作，具有非常复杂的依赖关系（并且可能强烈需要重构，但这是另一个并行问题）。到目前为止，我们在实施 DI 方面做得很差，我真的在努力让我们朝着正确的方向前进。在动态语言和 IoC（或至少 IoC 容器）方面似乎一无所有。
我是否最好暂时将依赖项“手动串起来”，然后在我更好地处理原则之后担心以后在容器中自动化它？是否值得实现我自己的简单 IoC 容器？还是说这些好处最终不值得在 PHP 中付出代价？
对于 PHP，请尝试Symfony 依赖注入。它基于 Java Spring 的工作原理（据说 - 我的经验太少，无法验证），但也使用了很多 PHP 的“魔法”。因此，它非常轻巧且易于使用，同时能够做很多事情。
首先修复您的依赖问题。如果您将 IoC 容器用作处理您的依赖项的包，那么它会非常难受，不会太远。
IoC 容器应该给你一个 API/词汇来讨论系统架构。
依赖注入导致您使用较小的解耦类作为子系统的构建块。这很好，因为它可以让您单独测试构建块并更轻松地对其进行推理。（你可以把它们想象成电路中的电子元件）
IoC 容器应该为您提供一种清晰表达这些构建块组成的方法。（将组件连接在一起的接线图）
有了这种分离，您还可以开始考虑子系统的生命周期……何时使用工厂、注册表、如何在系统中传递消息而不引入耦合……等等。
IOC 的重点是给你一个明确陈述所有这些逻辑的地方，而不是为你神奇地解决它。
我希望这有帮助。
如果您认为您的 IoC 是/可以比其他框架已经拥有的更轻量级，并且如果您有足够的时间来开发它，那么请构建您自己的。我个人在我的 MVC 框架中使用 IoC 只是为了将视图链接到控制器。我管理视图及其来自注册表（标准化结构关联数组）的参数。模型作为外部服务处理。我还第一次在 Java 上发现了 IoC 和 DI，所以当我构建我的语言时，我尝试从两种语言（Java 和 PHP）中汲取精华。当然它没有将任何东西链接到任何东西，但对于我的情况，我不需要它，所以你也可能不会。
IoC 对于随着时间的推移提供灵活性很重要，但灵活性有多大？您是否使用许多外部组件？您是否使用标准插件和对象？PHP 不是 java，你没有那么多开发良好的 jars 和库，随时可以通过加载它并替换 XML 中的指令来指向它，想想看。
我在一个名为 Alfresco（文档管理系统）的优秀开源软件上发现了出色的 IoC 实现。它是一个集合了 JSF、Spring、Hibernate 和 freemarker 模板的产品，但正如我所说的，它是一个可以融入数千种商业模式的产品，它更像是一个高度先进的平台，可以无休止地改变，所以它需要高度灵活。
如果您正在开发一个有针对性的应用程序，旨在为一种商业模式和少数客户提供服务，那么投入 IoC 发展将使事情变得更加艰难而不是简单。
爱因斯坦说过，事情必须简单，但不能比实际简单。
如果您不想拥有过度设计的 DIC，而是希望以非常紧凑的方式提供您需要的所有内容，请尝试使用这个：Bucket ( https://github.com/troelskn/bucket )。DI 容器不需要更多。除了 Symfony 之外，它通常以一种非常危险的方式使用，作为服务定位器（更好的别名全局状态）。
Martin Fowler 写的这篇文章几乎是控制反转和依赖注入的圣经。他解释了如何实现 IoC 容器并讨论了不同注入机制的优点。http://martinfowler.com/articles/injection.html
无论您使用哪种语言，“手动串依赖”都是不可扩展的。这将很难维护，因为其他开发人员可能不知道所有手动拉线发生在哪里，所以当他们更改某些内容时，他们可能不会更改正确的内容。相比之下，将所有这些放在一个地方将使未来的更改更容易实施。IoC 有助于最大限度地减少重复代码，并确保关注点分离和一致的应用程序架构。
另一方面，听起来您手头有一个功能相当大的应用程序——除非您也有很多时间，否则如果它没有损坏，则可能没有必要修复。