Tag: Laravel

  • LaravelでService層とRepository層を取り入れる

    LaravelでService層とRepository層を取り入れる

    Laravelを使用したプロジェクトでServiceとRepositoryというLaravelの機能を使用する機会があったので、備忘録の意味も含めて紹介したい。 対象読者 Service、Repository、Controller、Modelの関係性 今回は下記の流れになる Controller →Service →Repository →Model 【Controller】①ControllerからServiceをインスタンス化し、メソッドを呼び出す❻Serviceから返ってきた整形されたデータをフロントに渡す 【Service】②Repositoryのメソッドを呼び、Controllerから受け取ったIDなどのデータを渡したりする❺Repositoryから返ってきたデータを整形し、Controllerに返す 【Repository】③クエリを記述してDBからデータを取得する❹Modelから取得したデータをServiceに返す Service層とRepository層を取り入れるメリット、デメリット メリット ・DB操作をControllerで行わない事によりControllerのコード数が増える、いわゆるファットコントローラーになる事を回避できる。 ・処理を分担する事により、可読性、保守性が向上する。 デメリット ・中〜大規模プロジェクト向けという事もあり、小規模プロジェクトでは処理を分ける事に煩わしさを感じる可能性がある 実際にやってみる 実行環境 テーブル構成はのようにしてみる id name created_at updated_at deleted_at 1 りんご 2022-01-01 2022-01-01 null 2 バナナ 2022-01-02 2022-01-02 null 3 ぶどう 2022-01-03 2022-01-03 2022-01-03 ディレクトリ構造 Controllerを作成 Serviceクラスを作成 Repositoryを作成 Modelを作成 実行結果 まとめ 以上がService層とRepository層を取り入れた実装方法となる。 今回は基礎的な処理のみの為、恩恵は感じ辛いかも知れないが実際に取り入れて頂ければ可読性、保守性の高さを実感して頂けると思う。 今後のプロジェクトでLaravelを使用する機会があった際には、積極的に採用していきたい。