2012-04-06 3 views
1

MVC4アプリケーションとNinject.MVC3でEF 4.3を使用しています。 コントローラは、-Repositoryスイッチを使用してMVCscaffoldされます。 MVCScaffolderは、Ebを使用してリポジトリクラス(および対応するIRepositoryインターフェイス)を作成します。このリポジトリクラスでは、DbContextから派生したオブジェクトが、常にスキャフォールドされたリポジトリ内のデータメンバとして「新規作成」されます。MVC3スキャフォールドリポジトリ内のシングルトンDbContextオブジェクトを取得

MyContext context = new MyContext(); 

コントローラの足場の性質は、コントローラごとに、通常は対応するリポジトリも取得するようなものです。

質問:

1)それはあなたがのためのコントローラを持っている各ドメインオブジェクトのリポジトリを持っている意味を成していますか? これは集計根だけが
であるリポジトリパターンと比べて直観に反しているようです。

2)それが リポジトリ・オブジェクトがインスタンス化されるか、またはそれがDIコンテナに登録 DbContext派生オブジェクトのシングルトンインスタンスを有することが意味をなすない毎回発生DbContext派生オブジェクトの新しいインスタンスを有することが意味を成しませんアプリの起動などのような シングルトンのリポジトリにそれを解決:

Bind<MyContext>().To<MyContext>().InSingletonScope(); //ninject code on app startup 


//resolve context in repositories: 
MyContext context = ServiceLocator.Current.GetInstance<MyContext>(); 

は、任意の欠点は、アプリケーションの存続期間 シングルトンとしてDbContext派生オブジェクトへの保持にありますか?

ありがとうございました。

答えて

2
  1. これは予想通りです。実際のリポジトリを使用する場合は、集約ルートを使用します。リポジトリは常に固有なので、これらのリポジトリは自分で作成します(自動生成なし)。 generic wrapper around EFが必要な場合は、現在のソリューションを使用します。 T
  2. 通常、コントローラが複数のリポジトリを使用し、すべてのリポジトリでデータを一緒に保存する作業パターン(作業単位)を調整する必要があるシナリオでは、HTTP要求ごとに新しいコンテキストが使用されます。 Don't use singleton context!
+0

これは私も同様に傾いていたものでした。確認していただきありがとうございます –

関連する問題