在实现改变时使用依赖注入的优势

本文关键字：注入 依赖 实现 改变 | 更新日期: 2023-09-27 18:02:47

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

我使用以下代码应用了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，这就是为什么我要尝试使用它。

谢谢

在实现改变时使用依赖注入的优势

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

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

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

Di容器然后检查依赖项和它们的依赖项，然后用所有需要的依赖项自动注入构造对象。

一个DI容器是一个工厂，虽然你不需要编写，但只需要配置。然而，对象应该被设计成通过构造函数接受所需的依赖关系，这些深度应该是抽象的。DI部分是这样一个事实:你的对象不管理深度，但它让它们被注入。

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

相关文章：