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 Container作为对象工厂。

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

DI容器是一个工厂，虽然您不必编写，但只能配置。但是，对象应该被设计为通过构造函数接受所需的依赖项，并且这些deps应该是抽象的。 DI部分是这样一个事实，即您的对象无法管理deps，但它会被注入。

当使用DI容器并且事情发生变化时，您需要更改容器配置，但这就是它。

在实现更改时使用依赖注入的优点

1 个答案: