deha magazine / Laravel / 【拡張性・保守性バツグン】Laravelのリポジトリパターンとは【Repository】

【拡張性・保守性バツグン】Laravelのリポジトリパターンとは【Repository】

2020/07/14

PHPの人気のフレームワークLaravelを活用すると短期間でWebアプリケーションを作ることができます。

そのLaravelではリポジトリパターンを活用することで、チームでソースの開発・保守がしやすくなったり、データの構築などで変更が生じる場合にソースの変更がしやすいなどと言ったメリットがあります。

この記事ではそんなリポジトリパターンについて、どう言ったものなのか・どのように実装するのかを徹底解説していきます。

  • Repositoryデザインパターンについて詳しく知りたい方
  • Laravelに興味がある方

これらに当てはまる方におすすめの記事となっています。これを読めばRepositoryデザインパターンについて、どのように活用していけばいいかがわかりますよ。

Repositoryデザインパターンとは

これは高度なデザインパータンですので初心者のエンジニアさんはあまり気にしないかも知れませんが、IT会社で勤務経験のあるインターンシップは必ずトレーナーから教えてもらったかと思います。

Repositoryデザインパターンは.NET、Java、 PHP等多くの言語・フレームワークを使っており、ウェブサイト、サービス、アプリケーションからモバイルアプリまで幅広く使用されています。

RepositoryデザインパターンはBusiness LogicとData Sourceの中間クラスにあるものです。この中間クラスにあるオブジェクトはRepositoryと呼ばれます。そして、 Business LogicとData Source をお互いに呼び出し合うために、Interface経由で実施されます。

これによってアウトプットデータを標準化させ、ビジネスロジックとデーターアクセスロジックを分けて処理することが出来ます。

また、ビジネスロジックもデータソースの処理に関係なく、異なる処理を行います(その逆も同じです)。この分割処理の目的はそれぞれのパーツを自己分担することが出来ます。こうする事でソースの構築が綺麗になり、保守しやすくなります。

Repositoryデザインパターンのメリット

  • チームでソースの開発・保守がし易い
  • データの構築、データソース、ビジネスロジックに変更が発生する場合、ソースの変更が少なく済む
  • ビジネスロジックとデータソースを分けて、テストする事ができる
  • アウトプットのデータの標準化
  • ソースの重複を防ぐことができる (DRY – Don’t Repeat Yourself).

Repositoryデザインパターンのデメリット

  • 開発時、ソースの行が多口なる。分けてRepositoryに入れて使い回す事を考慮する必要がある
  • 小規模の案件は導入しなくても良い
  • ミクロサービスの上昇に伴い、Repositoryデザインパターンをミクロサービスのそれぞれの箇所に入れると無駄になり、経費もかかる

Laravelでリポジトリパターン

Laravelでは、リポジトリはモデルとコントローラ間の「ブリッジ」として機能し、データクエリの処理場所でもあります。

これらのクエリは、コンローラーで実装する代わりにリポジトリに入れられます。コントローラは、モデルを直接呼び出すのではなく、リポジトリを介してデータソースへのアクセス・操作します。 クエリの実行方法はリポジトリ内に隠されます。(コントローラー自体は気にする必要はありません。正しくと十分なデータが返せられれば大丈夫です)

ビジネスロジックの処理はどうするの?

実際に、データの簡単なGet処理であれば、リポジトリを介してコントローラで直接呼び出すことができます。

複雑なビジネスの場合、コントローラとリポジトリの間にService層があります。これは、コントローラーがロジック処理をService層に転送することのみを担当することを意味し、Service層はビジネスロジックが実装され、データソースに更新される場所です。

リポジトリパターンを実装してみましょう!

システムのほとんどはユーザーモデルがあるので、今回は例として紹介したいと思います。

まず、UserModelを作成します。

次はUserControllerを作成します。

UserControllerでは、データを照会するためにUserが直接呼び出されます。 ユーザーがデータのクエリ方法を変更するまで、すべてが順調に進みます。

ユーザーはuser_codeでソートされ、ユーザーの詳細ページはidではなくuser_codeでクエリされます。お客様の要件に合わせてデータを照会するようにコントローラーを更新する必要があります。

これは非常に危険で無駄な操作です。 UserControllerがこのような操作を実行するだけでなく、他の多くのコントローラーでも同じことを行うことを想像してください。 非常に多くの場所のコードを更新すると、見逃したり、誤動作したりする可能性が高くなります。

そして、以下はリポジトリを有効にするときです。

下記のようにリポジトリを作成します。

コントローラを更新します

したがって、今後、ロジックを追加する必要があるときはいつでも、それをリポジトリに追加するだけです。

まとめ

いかがでしたか。本日はLaravelのリポジトリパターンについて紹介していきました。

Repositoryデザインパターンはチームでソースの開発・保守がし易く、拡張性・保守性にも強みを持っています。

ぜひ開発に役立ててみてはいかがでしょうか。

また本日紹介したようなLaravelのリポジトリパターンを外注するのもおすすめです。 dehaソリューションズではオフショア開発によって低コストで迅速な開発をサポートしています。

Laravelに関して詳しくお話を聞きたい方、開発相談や無料お見積りをしたい方はこちらからご気軽にお問い合わせください。

▼ dehaソリューションへの簡単見積もりの依頼はこちら

Laravelシリーズ

【Laravel入門者向け】Laravel6系+PHP7.4でMVCの流れをサクッと試す (Mac編)

Laravel(API)とNuxt.jsの連携を行う【Laravel6+Nuxt.jsで作る管理画面】

CookieによるAPI経由のユーザー認証機能を作る【Laravel6とNuxt.jsで作る管理画面】

Nuxt.js+VuetifyとLaravelでCRUD機能を作る

見積もり・資料請求
見積書やオフショア開発の詳細資料を無料でお送りします
お問い合わせ

オフショア開発ガイド

オフショア開発のご相談や お見積りはこちらから

CONTACT