代码之家  ›  专栏  ›  技术社区  ›  Francisco Vilches

我们真的需要在Repository或UnitOfWork类中实现IDisposable吗?

  •  3
  • Francisco Vilches  · 技术社区  · 7 年前

    弗斯特 ,让我们看看微软对Asp.Net核心默认依赖注入服务的看法:

    https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.1#disposal-of-services

    也就是说,框架将调用类Dispose方法(假设类实现IDisposable)

    第二

    第三 ,在Startup.cs类中,我们通过AddDbContext方法添加DbContext,默认情况下,该方法被添加为作用域实例(即,在每个请求上创建并垃圾收集DbContext)。

    https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.1#service-lifetimes

    例如。

    public void ConfigureServices(IServiceCollection services)
    {
        services
            .AddDbContext<TheStoreDbContext>(ConfigureDbContext)      
            .AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2) 
    }
    

    那么,为什么网上和教程中有这么多的例子告诉您必须在存储库或UnitOfWork类中实现IDisposable呢?

    例如。

    public class UnitOfWork : IUnitOfWork
        {
            private readonly DbContext _context;
    
            public IProductRepository ProductRepository { get; }
    
            public UnitOfWork(DbContext context)
            {
                _context = context;
                ProductRepository = new ProductRepository(context);
            }
    
            public void Dispose()
            {
                _context.Dispose();
            }
        }
    

    1 回复  |  直到 7 年前
        1
  •  9
  •   Steven    7 年前

    你的例子 UnitOfWork 拥有 单位工程 然而,事实并非如此 拥有 这个 DbContext 单位工程

    出租 单位工程 把它处理掉 数据库上下文 单位工程 无法知道是否 数据库上下文 仍然由系统中的其他类使用 已处理。换句话说,系统可能会在 开始处理依赖关系。

    ,意思是 实施 IDisposable 完全。这意味着你让“其他人”控制了你的生命 .

    在依赖项的生存期内移动控件的想法(例如 )对于第三方来说并不是什么新鲜事,当然也不是特定于新的microsoftdi容器的事。事实上,这是一个古老的想法,即在应用程序的启动路径中集中控制应用程序组件的生命周期。在DI的上下文中,这个启动路径通常被称为 Composition Root .

    作曲家 Pure DI .

    推荐文章