2

これは解決された問題でなければなりません。答えが見つからないようです...

Ninject IoC コンテナーを使用するクラス ライブラリに WPF フロントエンドがあります。各Viewは、コンストラクターによって注入されたModelを取得するViewModelを使用し、 Modelは から派生したクラスをそのコンストラクターでも受け取ります。DbContext

これらの単語を入力すると、 から派生したクラスを作成するファクトリを注入することでこの問題を解決できることに気づきますが、ここで問題をコンテキストDbContextに入れるだけで終わります。

このセットアップにより、各ウィンドウが作業単位を所有するようになります。これはまさに私が望んでいるものです。問題は、これらのウィンドウの 1 つで、コンテキストからすべてのエンティティをリロードする変更破棄コマンドが必要なことです。

これを行う唯一の信頼できる方法は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にはファクトリクラスの必要性をおそらく排除できるFactory拡張機能があることも知っていますが、最後に使用したときに壊れました-クラスライブラリはVB6 ActiveX DLLで使用できる必要があり、ファクトリ拡張機能は気に入らないようですそれ。

4

0 に答える 0