Question

我在一个项目中使用Autofac，但我正在尝试做对。因此，我一直在阅读文档并发现Owned<T>。似乎是我想自己处理某些事情时使用的正确关系类型-例如DbContext，它是一次性的。

因此我将所有注入的工厂Func<DbContext>更改为Func<Owned<DbContext>>。

唯一的事情是Lazy<T>这样的行为有点脏，并且根据非框架类型将Owned放在使用中……

完全不使用Owned是错误的吗？

像这样处理我的班级不拥有的实例时是否存在问题？

public class MyClass
{
    private readonly Func<DbContext> _dbcFactory;

    private MyClass(Func<DbContext> dbcFactory)
    {
        _dbcFactory = dbcFactory; // nullcheck etc;
    }
    private void TheMethodWhoUpdate(String newName) 
    {
        using(var dbc  = _dbcFactory())
        {
            var ent = dbc.Table.Single(x => x.id == 3);

            end.Name = newName;
            dbc.SaveChanges();
        }
    }
}

我能想象到的（因为我在文档上找不到线索）可能会导致一些性能问题，因为autofac可能会跟踪创建的DbContext实例并尝试再次处置它，从而丢失一些时间（可能很小）...但是也许我错了，我应该坚持使用guide。

Answer 1

为什么不像代码示例中那样使用Func<DbContext> dbcFactory？

出于两个原因，您不应该这样做。

处理它是容器的工作-所以让它去做它的工作。
第二，如果您将DbContext注册为 InstancePerLifetimeScope，然后是多个对象（相同的生命周期范围）将获得相同实例 DbContext-如果其中之一将其销毁，这是有问题的从另一个下面。

Answer 2

当仅具有一个dbcontext实例（或仅有其他任何类）时，这不是一个选择（有很多原因使我不在此讨论），创建新实例是完全可以的。

在坚持依赖注入模式的同时，获得工厂注入而不只是一个实例是一种方法。

关于Func<Owned<T>>与Func<T>，我刚刚发现让范围发挥作用的困难方式是一个坏主意。

我使用了Func<Owned<T>>方法，但是即使我处置了所有自有的作用域，我仍然会遇到巨大的内存泄漏。

对我来说真正有效的方法是注入一个创建dbContext的工厂（或者您在有限的时间内需要的任何东西，或者需要控制生命周期的东西）。

该工厂应注册为一个实例。

我应该处置非拥有的实例吗？

2 个答案: