この記事の目的
この記事では、
Repository Patternとは何かを考えること
を目的としています。
本題
★Repositoryパターンの目的
Repositoryパターンの目的は、「データアクセス処理」と「ビジネスロジック」を分離することです。
Mirosoft Docsでは、以下のように記載されています。
"リポジトリ パターン" とは、データのアクセスをインターフェイスの抽象化の背後に分離する設計パターンです。 データベースへの接続やデータ ストレージ オブジェクトの操作を、インターフェイスの実装によって提供されるメソッドを使用して実行します。その結果、データベースに関する問題 (接続、コマンド、閲覧者など) に対処するためにコードを呼び出す必要が生じません。
★（個人的に）よく使うアプリケーション実装パターンとの違い
アプリケーション開発に携わるようになってから今まで作ってきたアプリは、大体次ような構造で設計されていました。
プレゼンテーション層で画面（ユーザーが操作するところ）の表示制御を行い、
ビジネスロジック層で、業務的な計算や集計処理を行い、
データアクセス層で、SQL文を構築しDBにクエリを発行する。
それら３つの層の間を必要な情報を格納されたインスタンス（ビジネスEntity層）が行き来して情報をやり取りする。
という構成です。
この図にむりやりリポジトリパターンを当てはめてみると、以下のようになると思います。
ビジネスロジック層では、データベースなどのリソースを意識せず、ビジネス処理を実装することができます。また、リポジトリは、インターフェースさえ実装しておけばよいので、テスト用のモックを作成しておくことができ、ビジネスロジックの単体テストが楽にできるようになります。
★Repositoryパターンのスタンダードな実装方法
スタンダードな実装はMSのDocsで紹介されているものになるのでしょうか。
https://docs.microsoft.com/ja-jp/aspnet/core/fundamentals/repository-pattern?view=aspnetcore-2.1:embed:ite
★メリット
★デメリット
これといったデメリットが出てこない・・・
調査不足ですねｗ
単純に調べ切れていないだけだと思いますが、気になったことをメモしておきます。
- トランザクションについて
従来の3層構造の場合、多くはビジネスロジック層でトランザクションを管理していましたが、Repositoryパターンではどこで管理することになるのでしょうか・・・
- 複雑なデータアクセスが必要な場合とそうでない場合の実装。
すべてのデータアクセス処理をリポジトリに集約すればいいのか・・・そうではないのか・・・
- リポジトリの作成単位
ベストプラクティスが見えない(-_-メ)
☆実際の使われ方
Log4netでも使われていました。Log4netのRepositoryパターン適用例（クラスの依存関係）は以下の通りです。
ここで、[ILoggerRepository]は、[Ilog]というインターフェースの実装クラスの情報を取得するために利用されます。※IlogはLog出力処理を司るクラスです。このRepositoryを介して取得したインスタンスを利用してログの出力メソッド（Info,Warnなど）を呼び出すことができるようになります。
Log4netでは、データベースから情報を取得するのではなく、設定ファイル（app.configやlog4net.config）から情報を取得します。DBだけにとらわれず、いろいろな「情報」を定義しているリソースからの取得処理と、ビジネスロジックとの分離ができそうということが見て取れます。
