しばらく前に、私は EF を DAL として使用し始め、チュートリアルとビデオから、リポジトリ パターンと作業単位パターンについて知るようになりました。
リポジトリについては、これが DAL の抽象化であり、ビジネス ロジックをデータ アクセス コードから分離していることを知りました。また、データ アクセス コードのレピュテーションを回避し、単体テストに役立ちます。
リポジトリ パターンは、DAL を作成する特定の方法であることを理解しています。しかし、それは何をもたらしますか？私は得ていません。私の混乱は、DAL (別のクラス ライブラリ/プロジェクト) を作成することです。これにより、これらの利点も得られます (データ アクセス ロジックをビジネス ロジックから分離し、データ アクセス コードの評判を保存し、単体テストに役立ちます)。
おそらく、私はまだリポジトリ パターンの利点を見逃しています。これについて私を案内してください。
データ アクセス レイヤーは、データベースなどのデータ ソースを処理することになっていますが、MSDNで説明されているように、より高いレベルの目標を達成するには、リポジトリ パターンが必要です。
MSDNによると
- 自動化でテストできるコードの量を最大化し、データ層を分離して単体テストをサポートする必要があります。
- 多くの場所からデータ ソースにアクセスし、集中管理された一貫したアクセス ルールとロジックを適用したいと考えています。
- データ ソースのキャッシュ戦略を実装して一元化したい。ビジネス ロジックをデータまたはサービス アクセス ロジックから分離することで、コードの保守性と可読性を向上させたい。
- 実行時ではなくコンパイル時に問題を特定できるように、厳密に型指定されたビジネス エンティティを使用する場合。
- 動作を関連データに関連付けたい。たとえば、フィールドを計算したり、エンティティ内のデータ要素間に複雑な関係やビジネス ルールを適用したりします。
- ドメイン モデルを適用して、複雑なビジネス ロジックを簡素化したい。