Question

方式1新实例

     public class LogicPacker : ILogicPacker
     {
         private IClassDI ClassDI { get; set; }
         public LogicPacker (IClassDI ClassDI){
              this.ClassDI = ClassDI;
         }


         private ICommentervice ICommentervice { get; set; }
         public ICommentervice Commentervice
         {
             get { return ICommentervice ?? (ICommentervice = new Commentervice(ClassDI)); }
             set { ICommentervice = value; }
         }
     }

方式2 AddScoped

    public void ConfigureServices(IServiceCollection services)
    {
        //IClassDI is absolutely add scope not change
        services.AddScoped<IClassDI , ClassDI>();
        ...
        services.AddScoped<ICommentservice, Commentservice>();
    }

下面是我的服务类

    public class Commentservice : ICommentservice
    {

         private IClassDI ClassDI{ get; set; }
         public Commentservice(IClassDI ClassDI)
         { 
             this.ClassDI= ClassDI;
         }
    }

在我的代码中，我不确定使用ioc AddScoped或新实例之间的性能。方式1我认为当我需要注入其他类评论服务时将会遇到麻烦将来会让我感到困惑和讨厌。但是方式1当我在ILogicPacker中有更多类时，我只是注入ILogicPacker并且不需要再向其他类注入服务需要使用服务（如果注入很多它将是构造函数的新实例，我认为）方式2是使用ioc添加到启动并且不用担心di的数量需要注入服务。如果有什么我觉得它错了告诉我并评论。

Answer 1

这不是关于性能，而是关于管理生命周期和范围。虽然实例化一个类会产生一些性能损失，但它通常太小甚至不能记录，如微或甚至纳秒。使用DI的原因是为了确定依赖关系的范围并重用依赖关系。

例如，考虑DbContext。它处理诸如更改跟踪和实现对象缓存之类的事情，启用关系修复等功能，而无需发出其他查询。但是，要使这些功能正常运行，您需要在任何地方使用相同的实例。如果您每次使用它时都创建一个新实例，那么更改跟踪可能会起作用，有时会带来灾难性的影响，至少，您会失去它提供的所有各种性能优化。 DI容器允许您共享这样的依赖关系而无需考虑它。

还有处理对象处理的问题，很多人都没有想到。如果你在课堂上新建了一堆东西，你也应该在不再需要的时候处理这些东西。这是通过IDisposable界面处理的，这似乎很难正确实现。如果你没有处理你新出现的东西，那么你基本上就会泄漏记忆。当然，GC会在你之后最终清理，但依靠GC只是糟糕的设计。 DI容器也考虑到了这一点。它控制它注入的对象的生命周期，并在真正有意义时处理它们。你的课程只是注入了依赖关系，所以它不再是类了。关注何时或是否处置资源。当然，减少顾虑是良好设计的基本范例。

service.addscope与新实例类之间的性能差异

1 个答案: