Laravelを使ったwebアプリを開発する際のRepository パターンについて

はじめに

今回はLaravelを使ってwebアプリを開発する際に必要な考え・デザインパターンを整理します。

まずLaravelはMVCモデルという、プログラムの処理をModel（モデル）・View（ビュー）・Controller（コントローラー）に分ける設計手法を採用しているフレームワークのことです。

(RouteはHTTPリクエストを受取ったら実行する処理をControllerへ割り振り、返ってきた処理の内容をHTTPレスポンスとしてブラウザへ返すパーツ)

MVCモデルを使うことによって、データの新規登録や変更、削除などDBとのやり取りを行う部分、
データの受け取り・受け渡しやどのデータを取得するかなどの処理を行う部分、ユーザーに表示する画面を整える部分に分けられ、どこにどの処理が書いてあるかが明確になり保守性や開発の際の効率アップが期待できる。

機能が多いサイトになるとそうもいかない

Contorollerでは、ユーザーからのリクエストによってデータをModelを通して登録・加工・取得したり、Viewへデータを渡すなどの処理を書きますが、機能が多いサイトになるとDBのテーブルが何十個となり、それに伴いこのテーブルからこのデータを取得きてこっちのテーブルからはこのデータを取得してきてなど、Contorollerのコード量が膨大になり読みにくく修正もしづらくなってしまいます。

Repository パターン

そこで開発前にRepositoryパターンというデザイン設計を使って、コードを整理して開発していこうと決めます。
ModelはDBとやり取りを行うパーツだと上に書きました。
Repositoryパターンとは、Controllerに記述するModelからDBへアクセスする処理だけを分離させるデザイン設計です。

処理の流れとしては下記の通りとなります。
controller ⇄ Model
↓
controller ⇄ Repository ⇄ Model

Serviceについて

またLaravelにはServiceという機能があり、Serviceは「メールを送る」「文字列を暗号化する」などの処理機能を持つクラスを定義させることで、Contorllerからコードを分離させることができます。これにより更にコードが管理しやすくなります。

処理の流れとしては下記の通りとなります。
controller ⇄ Model
↓
controller ⇄ Service ⇄ Repository ⇄ Model 


RepositoryパターンとServiceを使うことで、コードの管理がしやすくスムーズな開発や修正が行えるようになります。

参考

• Ritolab LaravelでRepositoryパターンを実装する-入門編
• Qiita LaravelでService層、Repository層を取り入れる方法とその必要性を簡潔に語る
• AIZULAB BLOG  LaravelでService層とRepository層を取り入れる