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