c# - リポジトリ / UoW - 使用するか使用しないか?

Question

私はこれが何百万回も前に行われたことを知っていますが、私はまだどちらに行くべきか2つの心にあります:

DbContextなどをモックできるため、UoW /リポジトリレイヤーは冗長であるようです。これにより、実装が簡単になり、サービスをEFに近づけると、より用途が広いように見えます。

これについて誰か良いアドバイスはありますか？

これに関して私が持っている 1 つの質問は、Ninject を使用して接続することです。Web 側でサービスに DbContext を挿入する場合は、EF への参照が必要です。これは間違っているようです。

kernel.Bind<FunkySoftwareContext>().ToSelf().InRequestScope();

これに対抗する方法はありますか？

score 2 · Accepted Answer

正しい抽象化が必要かどうかによって異なります。

サービス層は、データベースエンティティを公開しないでください。適切なビジネス/ドメインモデルを公開する必要があります。db エンティティとまったく同じように見える場合とそうでない場合があります。

それがリポジトリパターンの良いところです。ビジネスモデル表現を取得し、データベース/orm が使用できるものに変換します (逆も同様です)。

しかし、エンティティフレームワークから読み込まれたオブジェクトがドメイン/ビジネスモデルの完全な表現であると判断した場合は、リポジトリをスキップしてください。

私はそれについてブログエントリをここに書きました: http://blog.gauffin.org/2012/06/protect-your-data/

score 1 · Accepted Answer

DbContextなどをモックできるため、UoW /リポジトリレイヤーは冗長であるように見えます。これにより、実装が単純になり、サービスをEFに近づけることがより用途が広いように見えます。

リポジトリパターンが使いすぎていることに気付いたとしても、EF自体はDbContextを使用してUoWを実装し、DbSetを使用してリポジトリを実装します。したがって、アーキテクチャにUoW/Repositoryを追加する必要はありません。

これについてさらにアドバイスが必要な場合は、こことここにあります。またはAyendeからのアドバイス：こことここ

score 1 · Accepted Answer

（これはコメントのつもりでしたが、大きくなりすぎました！）質問が2つある場合は、2つの質問をする必要があります。これが Ninject の質問である場合、私はそれに答えますが、タイトルはそうではないことを示唆しています。

要約すると、単一のコンポジションルートがバインディングプロセスを管理するのは正しいため、最終的には何か(@jgauffin の回答を参照) になりInRequestScope、それが CR にあると言うのに適切な場所になります。

他のアプローチ (すべての UOW MVC リポジトリの InRequestScope Q & As を読んでください) は、ビジネスレイヤーサービスクラスをコントローラークラスに注入することです。

その下の一部のタートルがDBContextIDisposableを使用している場合は、それを管理するためのより良い方法である可能性があります。
(より理想的には) コントローラーが UOW を明示的にコミット (および失敗に対処) できるようにします (フィルターなどによるキャッチオール処理を完全に排除するわけではありません) 。Controller が DBContext と直接やり取りすべきだと言っているわけではありません。

3 に答える 3