2

リポジトリ パターンとそのさまざまな実装に関するほとんどすべての記事を読みました。彼らの多くは、悪い慣行 (例:IQueryable<T>の代わりに使用IList<T>) などを判断しました。

そう：

  • MVVM アプリケーションで IoC を適用するには、リポジトリ パターンが必要ですか?

  • はいの場合、EF エンティティへの効率的な IRepository の実装は何ですか?

  • Repositories と UnitofWork の動作をテストするにはどうすればよいですか? インメモリリポジトリに対する単体テスト？統合テスト？

編集：回答によると、最初の質問を追加しました。

4

2 に答える 2

3

Ayende Rahien は、リポジトリhttp://ayende.com/blog/search?q=repositoryと、ORM を使用しているときになぜそれが悪いのかについて多くの投稿をしています。私はリポジトリが行くべき道だと思った。2004年だったかもしれませんが、今は違います。ORM はすでにリポジトリを実装しています。EF の場合は IDbSet です。そして DbContext は UnitOfWork です。EF やその他の ORM をラップするリポジトリを作成すると、多くの不要な複雑さが追加されます。

データベースと対話するコードの統合テストを行います。

于 2012-09-09T11:32:10.057 に答える
1

リポジトリ パターンは、EF を使用している場合に追加のレイヤーを追加するため、この追加レベルの間接化が必要であることを確認する必要があります。

リポジトリ パターンの元のアイデアは、データベースの構造の複雑さと知識から上の層を保護することです。多くの点で、EF の ORM モデルはコードをデータベース内の物理的な実装から保護するため、リポジトリの必要性は少なくなります。

2 つの基本的な代替手段があります。

  • ビジネス層が EF モデルと直接対話できるようにする
  • リポジトリ パターンを実装するデータレイヤーを構築します。このレイヤーは EF オブジェクトを POCO にマップします。

テストの場合:

  • EF を直接使用する場合は、ロールバックでトランザクション スコープを使用するため、テストによってデータが変更されることはありません。
  • リポジトリ パターンを使用する場合、Rhino モックを使用してリポジトリをモックします。

私たちは両方のアプローチを使用します。Repository パターンはより明確に階層化されたアプリを提供するため、おそらくより多くの制御を提供します。EF を直接使用すると、アプリのコードが少なくなり、ビルドが速くなります。

于 2012-09-09T11:09:44.130 に答える