🔖

士郎。Repositoryを導入するという事は、Eloquentモデルオブジェクトを使わないという事なんだ

2022/11/29に公開

概要

LaravelでService層以外にRepositoryを導入している記事をいくつか見かけたので、実際にプロジェクトに導入してみました。

ちゃっと「Laravel Repository」と調べると色々出てきます。
デザパタのRepositoryパターンをLaravelで取り入れてみましょうみたいな内容

public function hoge(User $user)
{
//処理
}

Userモデルの型としてcontrollerなどから受け取ったり、定義した場合Userモデルに依存する形になるのでRepositoryの

データの取得先がDBであっても外部のAPIであっても、それを意識することなくデータ操作を行うことが出来る

というRepositoryのメリットがまず死にます。

$user->hogehoge()とかも勿論ダメ

Repositoryパターンを導入するという事は、Eloquentモデル関連の便利な機能を使わないという事でもあります。

例えば、ルートモデルバインディングとか

自分は以下のようになんちゃってRepositoryを取り入れてみました。そして後悔しました。

本来あるべきRepositoryパターンは出来ない(Eloquentと離れたくない)ので、「集約」　としての役割で使用しようと試みました。

全てUserというドメインとして扱いたい為、各モデルに書く静的メソッドをUserRepositoryに全て集約させる。

モデルオブジェクトにはリレーションの定義などだけ記述する

Repositoryクラス外ではModelをデータとしてだけ扱い、Repositoryはデータベースアクセスの役割で扱う

はい、思いついた時は良さそうと思ったんですが上記のルールはクソです。
Modelの振る舞いにデータベースアクセス系のメソッドがあるので役割がグチャグチャになります。

中途半端に使うぐらいなら取り入れない方が良い。

本来あるべきRepositoryパターンを使いたければEloquent禁をしてまでやるメリットがあるかどうか考えましょう。