在我看来，我们的工作是解决客户的问题，而不是编写依赖注入（或日志记录、ORM等）框架。当存在适当的框架时，我认为您应该始终使用该框架。

此外，如果该框架是开源的，那么没有使用它的借口，因为您可以修复任何可能存在的缺陷。

我认为我们太经常失去我们的目标。作为程序员，我们容易专注于有趣的问题（例如编写依赖注入框架），并且拖延无聊的问题（为客户编写另一个CRUD应用程序）。 :D

我认为现在存在的DI框架相当牢固（至少对于.Net而言）……为什么要花那么多时间去“重新发明轮子”呢？

最初看起来做一个DI框架可能并不是一项很大的任务，但是如果您看一下像Castle和Spring.NET这样的框架所提供的功能，我可以想出更好的方式来利用这段时间。除非您需要真正特殊的东西，否则我建议采用其中一个可用的框架并借助其他人的工作。

我当然会使用其中一个可用的解决方案。虽然它起初很简单，但是一些功能（如各种代理功能）在全功能 DI 框架中确实不简单。也许你也想要一些 AOP（面向切面编程）功能？

但是任何体面的DI框架都应该对您编写实际代码的方式影响很小，因此可以认为这对您的代码并不那么重要。

对于付款方可能很重要。在您的情况下，我会选择一个带有源代码的 DI 框架，并熟悉那个源代码，而不是编写自己的框架。

DI框架一直在不断发展，它们也添加了额外的功能，例如使您的代码更容易进行测试。随着项目的发展，编写自己的DI框架可能会更容易出错，也可能更加复杂。

如果你需要DI，我建议使用它们，并选择支持较好的一个。

选项3：暂不使用依赖注入。

你刚开始一个新项目，真的需要一个 DI 框架吗？

开始开发项目，您可能会开始看到一些问题依赖项。一旦它们开始出现，您可以评估现有的 DI 框架，并决定哪些框架是适当的。

谁知道呢，你可能会发现你根本不需要一个 DI 框架。

甚至马丁·福勒也说过：

控制反转是框架常见的特征之一，但它是需要付出代价的。它往往很难理解，并且在调试时会导致问题。因此，总的来说，我更喜欢避免使用它，除非我需要它。这并不是说它是一件坏事，只是我认为它需要证明自己比更直接的替代方案更有用。

将此翻译成中文：http://martinfowler.com/articles/injection.html http://martinfowler.com/articles/injection.html

如果我是你，我会避免使用任何依赖注入，除非你绝对无法在没有它的情况下完成。

记住，在大多数情况下，YAGNI。

你可以将依赖注入部分封装起来，以便稍后切换 DI 框架，你不需要担心库依赖或更改代码。例如，不直接调用 container.Resolve，而是编写一个工厂类来调用 container.Resolve，并仅调用工厂类。