ポジトリークラスに入れるメリットと入れる基準

Question

Laravelの実践的な練習としてベストプラクティスと言われるものを見つけ、そこでは以下の様に記載されていたのですが、いくつか疑問点があり、今回質問させていただきました。

記載されていた内容で、行っていたこととしては、Controllerに記載されていたDBに関するロジックに関しては、Modelに記述しているという認識です。

ただ、それに関して以下の点が不明点です。

DBに関連するすべてのロジックはEloquentモデルに入れるか (〜省略〜) レポジトリークラスにいれます。

• まず、なぜ下記ではBadに値するのでしょうか？
• また、その場合全てのDB操作をModelで行ってはあまりControllerの意味がなくなってしまうといった点や、Modelが肥大化してしまうのではないでしょうか？

上記を踏まえた上でどの様な判断を行い、Modelにコードの記載を行うことがあるのか、またその判断基準や全てのアクションをModelに記載してしまってはダメだと思うので、どのアクションをModeに記載するのか、共通化したものとして捉えていいのかが質問点となります。

長くなってしまい、あまりうまくまとめることができなかったのですが、以上を踏まえ、ご回答
していただけると幸いです。

以下は記載されていた内容です。

ファットモデル、スキニーコントローラ

DBに関連するすべてのロジックはEloquentモデルに入れるか、もしクエリビルダもしくは生のSQLクエリを使用する場合はレポジトリークラスに入れます。

Bad:

public function index()
{
    $clients = Client::verified()
        ->with(['orders' => function ($q) {
            $q->where('created_at', '>', Carbon::today()->subWeek());
        }])
        ->get();

    return view('index', ['clients' => $clients]);
}

Good:

public function index()
{
    return view('index', ['clients' => $this->client->getWithNewOrders()]);
}

class Client extends Model
{
    public function getWithNewOrders()
    {
        return $this->verified()
            ->with(['orders' => function ($q) {
                $q->where('created_at', '>', Carbon::today()->subWeek());
            }])
            ->get();
    }
}

Comments

[hentaiman]

人それぞれ過ぎて回答付かなさそうだけど
自分だったらこのファイル構成でこう書くのにっていうのはありますか？
あればそれを載せましょう、そしたらより良くする為にはこうしようってツッコミ来ると思いますが
あと疎結合で調べてからもう一度参考サイト見直してみたらどうでしょう？

[m.ts10806]

「その人の感覚」「プロジェクトのルール次第」程度の回答ならできますが。

Answer 1

そのベストプラクティスは概ね正しいので従っていい。

Controllerは意味がないほど薄くていい。
リクエストを受け取ってレスポンスを返すことだけがコントローラーの仕事。

Laravelは「テストできるか」を基準にすればいい。
最初はコントローラーでEloquentモデル使っていい。それでもテストできる。

そのうち同じようなコードを書く箇所が増えてきたらモデルなどに移す。
これを分かってる人は最初からモデルに書くべきと言ってるけど
「いろんな箇所に同じコードを書いてると修正が大変」ってことを実際に自分で経験しないと身に付かないので最初はコントローラーに書けばいい。

Comments

[m.ts10806]

「Laravelは」というか、昨今はテスト駆動開発もあるので、プロジェクト的なルールがない限り単体テスト基準でコード作っても良いですね。

[退会済みユーザー]

ご回答ありがとうございます。
例えば以下の回答であるとControllerで記述してもいいものかと思いますし、同じコードを各様には見受けられないのですがこの場合もModelに記載した方がいいのでしょうか？

Answer 2

まず、なぜ下記ではBadに値するのでしょうか？

ベストプラクティスに記載されている通り、単一責任の原則を守っていないためです。

また、その場合全てのDB操作をModelで行ってはあまりControllerの意味がなくなってしまうといった点や、Modelが肥大化してしまうのではないでしょうか？

単一責任の原則を守っていれば、不必要に肥大化することはありません。
不必要に肥大化しているならば、そのクラスは複数の責任を持っていることになります。

Modelにコードの記載を行うことがあるのか、またその判断基準や全てのアクションをModelに記載してしまってはダメだと思うので、どのアクションをModeに記載するのか、共通化したものとして捉えていいのか

LaravelにはMVCパターンが採用されていると思いますが、MVCパターンではロジックを全てModelに書きます。なので、Modelにコードを書くことはむしろ一般的です。

あくまでViewはページの表示やユーザーからの入力を受け付けるだけであり、Controllerはリクエストを受け取ってViewへの出力指示・Modelへの処理指示を行うだけです。

「その判断基準や全てのアクションをModelに記載してしまってはダメだと思う」と書かれているのはクラスやメソッドの肥大化を懸念してのことでしょうか。

であれば、pa843さんが懸念している通り、アプリケーションの規模や設計によってはModelが肥大化することがあります。

その場合は必要に応じてModelに ソフトウェアアーキテクチャ を取り入れてください。
例:レイヤードアーキテクチャ、クリーンアーキテクチャ、オニオンアーキテクチャなど

ソフトウェアアーキテクチャを取り入れることで、Modelのクラス・メソッドが責務単位で分割される（単一責任の原則が守られる）のでそれぞれの肥大化を防ぐことができます。

リポジトリークラスに入れるメリットと入れる基準

単一責任の原則を守れることがメリットです。
単一責任の原則を守ることのメリットは肥大化しないことです。
肥大化しないことのメリットは…、ここまで書けば、きっと大丈夫でしょう。

特定のクラス・メソッドが肥大化するなら入れるべきであるし、そうでなければ入れなくても良いでしょう。
どれぐらいのコード量で肥大化していると感じているかはその人次第なので、リポジトリークラスを入れる基準もその人次第です。

Comments

[BluOxy]

・各ソフトウェアアーキテクチャには利点や弱点があるため採用する前にそれ等を知ることが大切
・単一責任の原則を守ることのメリットは肥大化以外にも大切なことがあること
上記は本題から離れていくためこの回答では詳しく触れません。が、大切であるということは伝えておきます。

[退会済みユーザー]

単一責任の部分のベストプラクティスのコードが理解できなかったのですがご解説のほどお願いできないでしょうか？

[BluOxy]

コードのどの部分がどのように理解できないのでしょうか。
何が理解できていないかが分からないので解説できません。

という前提で1つアドバイスするならば、単一責任の部分のベストプラクティスのコードのBadとGoodでどのような記述の差異があるかを洗い出すところから始めると良いでしょう。

Answer 3

各々流派があると思うので私の回答も持論として聞いてください。

また、その場合全てのDB操作をModelで行ってはあまりControllerの意味がなくなってしまうといった点や、Modelが肥大化してしまうのではないでしょうか？

なるべく同じような処理を排除・統合しても、Modelにまとめていると次第にファット・モデルになってきます。これは、ファット・コントローラーと同じように避けるべきです。

例えば

• 処理ごとにモデルは分けられませんか？
• 「とりあえずリレーション定義」してませんか？
• データの整形をModelでやってませんか？
• scope使ってますか？

と言ったところです。

最初の「処理ごとにモデルは分けられませんか？」はやりすぎると死ぬので、ある程度慣れてきてからの方が良いと思います。