DIとリポジトリパターンは何が嬉しかったのか？がよくわからなくなった。

まだ色々考えている途中

qiita.com

上記のページからリポジトリパターンの良さを抜粋すると以下の様な事が挙げられている

テストがしやすくなる

DBエンジンの変更に対応しやすくなる

データ操作のロジックが1箇所にまとまり、管理しやすくなる

そうだよねと思いつつ、Laravel系でリポジトリパターンに言及している別のページも見て回った.　

結果、気がついた事が一つある。基本的に返り値を言及していない。

当たり前過ぎて言及されていない前提の話しなのかもしれないが。

例えば、SQLite様に書いたリポジトリがsqliteのコネクションを返し、Redis様にかいたリポジトリがredisのコネクションを返したら、リポジトリインターフェースを要求しているコードはそのDBエンジンに寄ってコードを書き換える必要が出てくる. それでは本来のリポジトリパターンの意味が薄いと思った。

DBエンジンをすげ替えられるようにpythonで書いてみた

とりあえず自分で書いてみたら答えが出るかもと思って、RedisとSQLiteと単なるモックコードを切り替えられるようにした。

以下のページの183行目で生成するクラスを変更したら使われるDBが変わるようになっている

github.com

実行結果は基本的に同じようになっているはず (だが途中でめんどくなってredisあたりのconfiguとか端折ってる)

書いてみた結論として

• たしかにテストはし易いはず
  • DI自体は例えばコントローラーのテストの際にmodelのモックが気軽に差し込めるのは良いと思う
• リポジトリパターンでなくても良いのでは?という気持ち
  • リポジトリパターン自体はインターフェースを統一させるための存在という認識
    • RDBMS -> RDBMS (例えば, MySQLからPostgreSQL) だけを考えるならばORMが似た事をカバーしてくれそう
    • NoSQLも同じ
      • KVSならKVS向けのwrapperがあれば良い
      • ドキュメント指向ならドキュメント指向のwrapperがあれば良い
  • NoSQLとRDBMSとではリポジトリインターフェースの互換性を維持するのがそもそも大変
    • どれくらい自前のコードで吸収するか？
    • 現実問題として、RDBMSなコードをRedisやMongoにすげ替える前に考える事がもっとありそう
• リポジトリに持たせる実装がもう少し厚い場合考えが変わるかもしれない
  • 現状リポジトリにはどの位の責務で実装を持たせたら良いのかがわかってない
  • が、DBを操作する系のメソッドが長くなるとその実装自体がテストできなくなるので…
• リポジトリパターンってなんだ？
  • アダプタ

ということで、本日のブログ 「DIとリポジトリパターンは何が嬉しかったのか？がよくわからなくなった。」 になる。

追加の参考

blog.comnect.jp.net

上記のリンクを見るに、自分の実装ではリポジトリパターンになっていなかった。

リポジトリ内で実装をすげ替えるより、リポジトリに対して更にクライテリアをDIするほうが責務としてはきれいに別れて良さそう.

だけど根本的な疑問として、そこまでしてRDBMSとNoSQLとの互換性を保ちたいか？と聞かれると微妙なのは変わらず.