refirio.org

未整理メモ

■Service層とRepository層 LaravelでService層とRepository層を取り入れる | システム開発部Blog https://enjoyworks.jp/tech-blog/7743 ・Service層を持つことで、クラスの責任範囲を分けることができる。業務ロジック単位で扱う。 ・Repository層を持つことで、処理の差し替えやテストを容易にする。データベーステーブル単位で扱う。 Repositoryをモック化すると、テストを容易にできる。 案件によっては、そんな思想で作られている。 色々参考にしつつ、最初にそんなレールを敷いたが、案件規模によっては無駄に複雑ではある。 単体テストなど厳密に書いているわけでは無いし。 案件の規模に応じて「コントローラー → サービス → モデル」や「コントローラー → モデル」でも問題無いと思う。 リポジトリパターンについては、以下なども参考になる。 LaravelでRepositoryパターンを実装する-入門編- https://www.ritolab.com/entry/165 Laravelアプリケーションでリポジトリパターンを使う方法 https://www.twilio.com/blog/repository-pattern-in-laravel-application-jp 「例えば、注文管理をサードパーティアプリケーションにアウトソースする場合」 で処理を差し替える場合などが大きなメリットだと思う。 ただし現実的には「注文管理をサードパーティアプリケーションにアウトソースしますが、それに伴いビューとかCSSも変わります。新規の機能も追加します」とかはありそうなので、そんな単純にはいかないとは思う。 また 「小規模のプロジェクトでは、このアプローチは多くの作業が必要で」 というデメリットもあるので、ケースバイケースではある。 ■サービスコンテナ サービスコンテナの仕組みに乗っておけば、処理の差し替えは契約インターフェイスの紐付けを変えるだけで対応できる？ただし小規模アプリケーションの場合は、無駄に複雑になる感は否めないが。 サービスプロバイダで処理の紐づけを変更できる。 ■リポジトリパターン考察 「例えば、注文管理をサードパーティアプリケーションにアウトソースする場合」 で処理を差し替える場合などが大きなメリットだと思う。 とするなら、リポジトリにwhereを長々書くのは思想的におかしいかもしれない。 とは言え、柔軟な検索をどう実現すべきか、そもそも汎用的な検索メソッドではなく、専用の検索メソッドを用意すべきなのかもしれない。 interfaceの継承がアリなら、契約用のインターフェイスはすべて共通の親クラスを作るか。 以下などによると、クラス設計的にはおかしなことは無さそう。 【PHP】interfaceは継承・多重継承が可能。読み込みの順番もあり？【697日目】 - エンジニアのひよこ_level10 https://www.nyamucoro.com/entry/2019/09/11/012246 ただし以下によると、機械的にCRUDを実装するのは良くないらしい。とは言え、同じ内容のインターフェイスが量産されるのも微妙だが。 Laravel におけるリポジトリ実装のポイント - Shin x Blog https://blog.shin1x1.com/entry/laravel-repository 「3. 機械的に CRUD メソッドを実装しない」 「機械的に CRUD を付けるというのは、データベーステーブルに対応するリポジトリを実装するという発想から来るものでしょう。そうではなく、リポジトリでは、対象のドメインデータが永続化層にどのような操作が必要かを考えて、それのみを実装すると良いです。」 CRUDな契約をinterfaceで定義して、その実装を抽象クラスとして実装するのはどうか。 そういう書き方が駄目なら、以前検証したとおりリポジトリごとにインターフェイスを作るか。 画一的に書くべきで無いなら、参照登録編集削除crudもしくは参照専用master、とか。 外部APIであっても、基本的にはそのどちらかになるはず。 PHPにおけるインターフェースと抽象クラス、多重継承、トレイトの使い方：PHPオブジェクト指向プログラミング入門（5）（1/2 ページ） - ＠IT https://atmarkit.itmedia.co.jp/ait/articles/1511/02/news016.html 運用時と開発時で、データの取得内容を差し替えられる。 また、リポジトリとモデルは対になることが多いが、それは絶対ではない。 常に別のリポジトリ経由でモデルを扱うことも考えられる。 リポジトリパターンと Laravel アプリケーションでのディレクトリ構造 - Qiita https://qiita.com/karayok/items/d7740ab2bd0adbab2e06 「AppServiceProvider で環境ごとに注入する Repository を変更します。」 「これにより、テスト環境のときはデータの取得方法を変更することができます。」 「Model と Repository は 1:1 とは限りません。」 ■その他 Service層とRepository層を作る意味。 具体例は Laravel6.txt を参照。 ただし後述しているように、Repository層は無くてもいいかもしれない。 以下は公式の説明だが、あまり解りやすいとは思わない。 サービスコンテナ 9.x Laravel https://readouble.com/laravel/9.x/ja/container.html 【Laravel】サービスコンテナとは？２つの強力な武器を持ったインスタンス化マシーン。簡単に解説。 - Qiita https://qiita.com/minato-naka/items/afa4b930a2afac23261b Laravel6.txt https://refirio.org/memos/technology/?file=Laravel6.txt 以前の勉強メモ。 「サービスとリポジトリを作成」部分を参照。 以下、Laravel経験者の方の意見。 ORMではEloquentとCollectionを使っている。 Eloquentの準備 9.x Laravel https://readouble.com/laravel/9.x/ja/eloquent.html コレクション 9.x Laravel https://readouble.com/laravel/9.x/ja/collections.html …がRepositoryがあることで、この恩恵を受けにくくなっている。 Repositoryをしっかり設計して思想を統一することで改善できるかもしれないが、中規模での開発なら 「コントローラー → サービス → リポジトリ → モデル」 よりも 「コントローラー → サービス → モデル」 の方がいいのでは。 非常に大規模な開発ならリポジトリ層が活きるかもしれないが、それならLaravelではなくSymfonyの方がいいかもしれない。 Laravelは色々簡単にできるようになっているが、Laravelの恩恵を受けるなら、リポジトリパターンは向いていないのでは。 検索の一部の処理だけ使っていたり、はある。 「こういう条件ではこういうwhereを書く」のような分岐処理など。 ただ、これはサービス層で吸収できるかもしれない。 以下も参考になりそう。 5年間 Laravel を使って辿り着いた，全然頑張らない「なんちゃってクリーンアーキテクチャ」という落としどころ https://zenn.dev/mpyw/articles/ce7d09eb6d8117