我平时只是把编写应用作为一种业余爱好。看起来DI框架在社区中有很大的推动力，所以我想学习它来提高我的编程技巧。据我所知，它似乎更适用于大型项目。但在一个5000行的项目中使用它是否仍然是一个好主意呢？
5个回答
3
是的，依赖注入有助于松耦合和可测试性，这对任何规模的项目都很有用，配置的开销相对较小。
- Lee
2
是的，假设您愿意将5k到20k行的项目转换为3k到10k行的项目。
是的，假设您希望在测试更大的代码库时编写更少的测试代码。
是的，假设您希望评估依赖注入是否有助于您成为更好的程序员。
- sal
1
实际上，依赖注入（DI）引入了一些“复杂性开销”（以及相对较小的大小开销），在较小的项目中可能看起来不值得。然而，熟悉DI并在适当的时候使用它有许多直接和间接的好处。特别是：
更直接地说
- 它使项目内部的组件/模块之间的耦合度降低。从而促进代码和模式（来自先前项目）的重用
- 通过更容易引入替代（模拟）真实依赖类型的类/模块，它有助于测试。
间接地说
- 它促进了接口的使用：通过接口（或抽象类）定义API方法的各种参数，而不是具体类型。
因此，即使在某个项目或其部分中没有使用DI，熟悉DI及其相关概念和模式也有助于使用更多抽象、更少“硬”依赖点和更清晰、更自我说明的对象模型来构建项目。
- mjv
1
如果您不使用依赖注入，则几乎可以确定您没有为单元测试使用模拟框架，或者根本没有进行单元测试。 单元测试的好处之一是，最终它将推动您使用更好的设计模式，包括依赖注入。 如果您不这样做，您会发现很难测试自己的代码。
对于您的规模应用程序是否需要学习如何使用DI框架是一个未知数。 向项目添加任何外部代码都会增加一些复杂性，老实说，我还没有发现足够吸引我使用它在我的项目中 - 至少尚未发现。 同时，我曾经手工创建所有我的模拟对象，自从转换到RhinoMocks后，我很少手工模拟对象，并且我感到我的生产力已经提高了。 DI容器是我要探索的下一个技术，但我还没有找到可用它尝试的项目。
我的建议是，既然您似乎愿意尝试，那么尝试一两个DI框架，看看它们对您的工作效果如何。 如果您没有发现足够的价值，则尝试手动注入 - 假设您还没有达到这一点，如果您已经达到这一点，请回到它上面。
- tvanfosson
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接