.net - 使用依赖注入框架还是自己编写？

Question

当开始一个新的应用程序时，您宁愿只使用现有的依赖框架并冒可能出现的缺点，还是选择编写自己的完全适应的框架，为什么？

score 15 · Accepted Answer

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

除此之外，如果该框架是开源的，那么没有理由不使用它，因为您可以修复任何可能的缺点。

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

score 5 · Accepted Answer

我认为现在的 DI 框架非常可靠（至少对于 .Net 而言）......为什么要花那么多时间重新发明轮子？

score 2 · Accepted Answer

最初，做一个 DI 框架似乎不是一项大任务，但如果你看看 Castle 和 Spring.NET 等框架提供了哪些框架，我可以想出更好的方式来消磨时间。除非您需要真正特别的东西，否则我会采用其中一种可用的框架并利用其他人的工作。

score 1 · Accepted Answer

我当然会使用其中一种可用的解决方案。虽然一开始很简单，但在全功能 DI 框架中，有一些功能（如各种代理功能）绝对不简单。也许你也想要一些 AOP？

但是任何体面的 DI 框架都应该对您编写实际代码的方式影响不大，因此可以争辩说它对您的代码没有那么重要。

不过，这对支付费用的人来说可能很重要。在您的情况下，我将获得一个带有可用源代码的 DI 框架，并了解该源代码而不是编写您自己的源代码。

score 1 · Accepted Answer

DI 框架一直在发展，它们也增加了功能，例如使您的代码更易于测试。随着项目的发展，编写自己的代码会更容易出错并且可能会更复杂。

如果您需要 DI，我会说使用它们并选择一个具有良好支持的。

score 0 · Accepted Answer

选项 3：不要使用依赖注入（暂时）。

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

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

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

甚至马丁福勒也说：

控制反转是框架的一个共同特征，但它是有代价的。当您尝试调试时，它往往难以理解并导致问题。所以总的来说，除非我需要它，否则我宁愿避免它。这并不是说这是一件坏事，只是我认为它需要证明自己比更直接的选择更合理。

如果我是你，我会避免使用任何依赖注入，直到你绝对不能没有它。

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

score 0 · Accepted Answer

您可以围绕依赖注入位编写一个包装器，因此如果您想稍后切换 DI 框架，则无需担心库依赖关系或在任何地方更改代码。比如不直接调用container.Resolve，写一个工厂类，为你调用container.Resolve，只调用到工厂类。

7 回答 7