当开始使用新应用程序时，您是想更好地使用现有的依赖关系框架并冒可能存在的缺点，还是选择自己编写一个完全适应的应用程序？为什么？
答案 0 :(得分：15)
IMO，我们的工作是解决客户端的问题，而不是编写依赖注入（或日志记录，或ORM等）框架。当存在合适的框架时，我认为应该始终使用该框架。
除此之外，如果该框架是开源的，那么就没有理由不使用它，因为你可以解决任何可能的缺点。
我认为我们常常失去目标。作为程序员，我们倾向于关注有趣的问题（例如编写依赖注入框架）并拖延无聊的问题（为客户编写另一个CRUD应用程序。）：D
答案 1 :(得分：5)
我认为现在的DI框架非常可靠（至少对于.Net）...为什么要花费所有时间re-invent the wheel？
答案 2 :(得分：2)
最初，做一个DI框架似乎不是一项大任务，但是如果你看一下像Castle和Spring.NET这样的框架，我可以想出更好的方法来花时间。除非你需要一些非常特别的东西，否则我会采用一个可用的框架并利用其他框架的工作。
答案 3 :(得分：1)
我当然会使用其中一种可用的解决方案。虽然它开始很简单，但有一些功能（如各种代理功能）在全功能DI框架中绝对不简单。也许你也想要一些AOP？
但是任何体面的DI框架都应该对你编写实际代码的方式产生很小的影响，因此有可能认为对你的代码来说并不重要。
虽然付钱的人可能很重要。在你的情况下，我会得到一个包含源代码的DI框架，并且知道那个源而不是自己编写。
答案 4 :(得分：1)
DI框架一直在不断发展，它们还具有其他功能，例如，使代码更易于测试。当项目增长时，编写自己的内容将更容易出错并且更加复杂。
如果你需要DI并选择一个有良好支持的人，我会说使用它们。
答案 5 :(得分：0)
选项3：不要使用依赖注入（还）。
你刚刚开始一个新项目。你真的需要一个DI框架吗？
开始开发项目，您可能会开始看到一些有问题的依赖项。一旦它们开始出现，您可以评估现有的DI框架并确定哪些是合适的。
谁知道，您可能会发现根本不需要DI框架。
即使是马丁福勒说：
控制反转是框架的一个共同特征，但它是有代价的。当您尝试调试时，它往往很难理解并导致问题。所以总的来说，我宁愿避免它，除非我需要它。这并不是说这是一件坏事，只是因为我认为它需要通过更简单的替代方案来证明自己的合理性。
http://martinfowler.com/articles/injection.html
如果我是你，我会避免使用任何依赖注入，直到你没有它完全无法使用它。
在大多数情况下，请记住YAGNI。
答案 6 :(得分：0)
您可以编写依赖注入位的包装器，因此如果您想稍后切换DI框架，则无需担心库依赖关系或在任何地方更改代码。例如，不是直接调用container.Resolve，而是编写一个为您调用container.Resolve的工厂类，只调用工厂类。