当实现发生变化时使用依赖注入的优势

Question

我正在开发一个小型控制台应用程序，并且正在记录事务。

我使用以下代码应用了 DI（Ninject）：

    class Program
    {
        private static ILogger _logger;        
        private static IKernel kernel;

        static Program()
        {
            kernel = new StandardKernel();
            kernel.Bind<ILogger>().To<Log4NetWrapper().WithConstructorArgument<Type>(MethodBase.GetCurrentMethod().DeclaringType);            
        }

        static void Main(string[] args)
        {
            _logger = kernel.Get<ILogger>();   
            try
            {   
                _logger.Info("Initializing...etc " + i.ToString() + ": " + DateTime.Now);
            }
            //etc...
        }
     }

效果很好，但后来我想使用 Factory 在另一个类中实现相同的结果（用于比较）：

public class TestLogFactory
{
    private static readonly ILogger _logger =
         LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);

    public void LogInfo(object message)
    {
        _logger.Info(message);
    }
}

第二种方法对我来说看起来更干净，如果我更改实现（替换日志实现）我只需要更改 LogManager 类，但在第一种方法中我需要更改注入依赖项的每个类。我的问题：在这种情况下使用第一种方法有什么好处吗？我正在学习 DI，这就是我尝试使用它的原因。

谢谢

Answer 1

这不是 DI，它实际上是一个 ServiceLocator 。您的应用程序需要 DI 是微不足道的，但在真正的应用程序中，DI 意味着这一点

class MyClass
{
         public MyClass(ADependency dep1,OtherDependency dep2){}
 }

这意味着，deps 由第三方（手动或使用 DI 容器）注入到对象中。通常，这些服务将由使用 DI 容器作为对象工厂的框架自动调用。

Di 容器然后检查依赖项及其依赖项，然后构造具有自动注入的所有必需依赖项的对象。

DI Container 是一个工厂，尽管您不必编写，只需配置即可。然而，对象应该被设计成通过构造函数接受所需的依赖，并且这些依赖应该是抽象的。 DI 部分是您的对象不管理 deps 而是将它们注入的事实。

当使用 DI 容器并且情况发生变化时，您需要更改容器配置，仅此而已。