2

这必须是一个已解决的问题，我似乎无法找到答案......

我在使用 Ninject IoC 容器的类库中有一个 WPF 前端；每个View都使用一个ViewModel ，该 ViewModel获得一个注入了Model构造函数的 ViewModel，并且Model接收一个派生自 的类DbContext，也在其构造函数中。

当我输入这些单词时，我突然想到我可以通过注入一个创建派生自 的类的工厂来解决这个问题DbContext，但我将在这里完成将问题放在上下文中。

这种设置使每个窗口都拥有一个工作单元——这正是我想要的。问题是，在其中一个窗口上，我想要一个丢弃更改命令，该命令从上下文中重新加载所有实体。

我读到唯一可靠的方法是Dispose根据上下文并重新实例化它。

  • Q1：这应该如何与依赖注入很好地配合？

我可能有这样的事情：

public class SomeModel : ISomeModel
{
    private readonly SomeContext _context;
    public SomeModel(SomeContext context)
    {
        _context = context;
    }

    /* some methods acting upon entities in _context */
}

我在想的是这样的：

public class SomeModel : ISomeModel
{
    private readonly IContextFactory<SomeContext> _factory;
    private SomeContext _context;
    public SomeModel(IContextFactory<SomeContext> factory)
    {
        _factory = factory;
        _context = _factory.Create();
    }

    public void DiscardChanges()
    {
        _context.Dispose();
        _context = _factory.Create();
    }

    /* some methods acting upon entities in _context */
}
  • Q2：这种方法是否存在任何已知问题/陷阱？

现在我DbContext像这样绑定，使用 Ninject 的 Conventions 扩展：

_kernel.Bind(t => t.From(_dataLayerAssembly)
                   .SelectAllClasses()
                   .Where(type => type.Name.EndsWith("Context"))
                   .BindDefaultInterface()
                   .Configure(config => config.InCallScope()));

如果我采用上述方法，我不再需要这种配置（除了我不能 100% 确定上下文在我认为它确实会被处理时）并且我可以完全控制上下文的时间线和处理......但是我觉得我正在打破模式中的某些东西——并不是说我很关心打破模式（不是“纯粹主义者”），尽管我很想知道 MVVM+DI“纯粹主义者”会如何处理这个问题。

我也知道 Ninject 有一个工厂扩展，它可能会消除对工厂类的需求，但上次我使用它时，它坏了——类库必须可由 VB6 ActiveX DLL 使用，而工厂扩展似乎不喜欢那。

4

0 回答 0