laravelでService Repositoryの概念で実装してみた感想

結論

SeriviceとRepositoryのlaravelへの導入方法は
いろんなサイトで紹介されているので、それぞれ試してみましたが
自分自身でコーディングしてみた感想としては
laravelのeloquentを使いたいならrepositoryは不要な気がします。
大規模なDBとかの経験がないだけなのかもしれないが。

Repositoryの導入途中で「あれ？リレーションはどうすんだ？」
「eager loadingつかえんのか？」とみていくと
withとかwithTrashedとか自前で実装しないといけないことに気づいた。

laravelのリレーションとかeager loadingとかの便利機能を使いつつ
SQL文を直接クエリで書きたいくらいのレベルでは
Repositoryは機能が重すぎる。

以下で十分。ViewはInertiajsを想定。

Controller

requestのバリデーションとresponseの行先のみ指定。

Controller.php

private: $someService;
public function __construct(SomeServiceInterface $someService)
{
    $this->someService = $someService;
}
public function store(StoreRequest $request)
{
    try {
        $this->someService->create($request->all());
        return redirect()->route('posts.index')->with(['message' => '追加しました。']);
    } catch (Throwable $e) {
        return redirect()->back()->with(['error' => $error_message]);
    }
}

Service

業務処理の実体。
interfaceは型を厳密にしたいときやメソッドの公開を限定的にしたい場合。

app/Services/SomeService.php

class SomeService implements SomeServiceInterface
{
    public function create(array $data): ?Model
    {
        DB::beginTransaction();
        try {
            $post = new Post($data);
            $post->save();
            DB::commit();
            return $post;
        } catch(Throwable $e) {
            DB::rollBack();
            return null;
        }
    }
}

Model

DBのテーブルのラッパー。
laravelのeloquentの便利機能を使いたいならこれで十分。

View

応答データ。webならblade、vue、react。apiならjson。