我对IoC和DI很新，我似乎无法找到我不应该使用它的确切场景。
在我知道有可能进行扩展（如基于文件的日志记录，数据库日志记录等）或使用数据源（测试，生产等）的地方使用它是有意义的。
但我感到困惑的是，如果我对所有这些项目使用IoC / DI，我可以在一个大项目中拥有数百个类，是否使代码管理/维护/单元测试变得容易？它只对这些类有帮助吗？
同样，如果我确定一个类总会创建另一个类的对象，例如客户将始终有一个地址，在这种情况下我应该使用DI吗？在这种情况下不使用DI是不好的做法吗？
我们即将使用ASP.Net MVC3开始一个大项目，Unity是一个不错的选择吗？
谢谢， 阿里
答案 0 :(得分：0)
在谈论IoC时需要注意的一点是，我们讨论的是对象之间的依赖关系，而不是类。如果您正在考虑I need that object, and I need it now!，这是DI的一个很好的候选人。将它作为构造函数参数传递给您的类是很自然的。