質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

87.94%

Laravel Repositoryパターンの実装に関して

受付中

回答 3

投稿

  • 評価
  • クリップ 1
  • VIEW 2,429

score 5

現在laravel5.5を利用してwebアプリケーションを製作しております。
db操作が多くなってきたことからrepositoryパターンの実装を検討しているのですが、実装する上でrepositoryに実装すべき処理の範囲が不明瞭になってしまったので、そちらに関してご教授頂きたく思います。

「コントローラ、サービス、リポジトリ、モデル」の4つがある場合に関してです。

まず私の現在のそれぞれに対する認識は以下のようなものです

コントローラー:

詳細なロジックは一切記述せず、サービスのメソッドを呼び出す役割と、ビューにレスポンスを返す役割を担う。

サービス:

ビジネスロジックを記述しdb操作を行う場合はリポジトリのメソッドを呼び出す役割を担う。

リポジトリ:

モデルを利用したDB操作を記述する。

モデル:

dbに対するsql発行をテーブルごとに分かりやすくしてくれる物であり、
独自にメソッドを追加すべきではない。

このような認識を持っていたのですが、先日他の方のコードを拝見させて頂いた際に、モデルに独自メソッドをいくつか記入しdb操作を全てモデルが担うように実装している方がいました(リポジトリは利用していない)

私はこの実装に納得してしまいました。
これならリポジトリパターンで行おうとしているビジネスロジックとdbアクセスの分離が問題なく出来ていますし、余計にリポジトリクラスを増やす手間も省けるではないですか。

だったら「なぜこの便利なモデルクラスというものが存在するlaravelでリポジトリパターンを実装したがる人がいるのか」と思ったわけです。

ど素人の考えですのでとんだ的外れな質問になってしまっているかもしれないのですが、以上を踏まえてリポジトリパターンのメリット、また実装時のモデルとリポジトリの使い分けに関してご回答いただけると幸いです。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 3

0

主観です

リポジトリパターン、DDD、クリーンアーキテクチャ等
色々なパターンがありますが、どれもこれも銀の弾丸ではありません。
これらは主に、コードの保守性、移植性を高める事に貢献しますが
開発工程を大幅に短縮するものではありません(長期的に見た場合は最終的なコストは下がります)
もし、あなたが早くプロダクトを形にしたい(特に市場調査が終わっておらず、市場に存在できるかが不確定な場合、いち早くMVPを作る必要があります)場合には
設計手法には拘らず、とりあえずMVCで動くものを作るべきです。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

PHPはよく知らず、今さっきググっただけの知識なので間違いがあるかもしれませんが、ご使用のフレームワークで言うところのmodelは、DBのとあるテーブルの構造ままを表したマッピング用のオブジェクトという認識でよいですか?

とりあえずORマッパーのように、フレームワークの文脈に従ってコードを書けば、簡単にオブジェクトを検索登録更新削除できるようなもの、という前提で話をします

リポジトリパターンは結局のところ、永続化層とのやり取りを抽象化してメリットを得ることを目的としたパターンと捉えてよいです(この手の何たらパターンというのは、大抵何らかの対象を抽象化する代物であることが多いです)

それによって、DB固有の問題やテーブル設計、ORマッパーなどのライブラリの仕様、そして、それらの変更に振り回されずに開発を進められることを期待しています

インピーダンスミスマッチという用語が示すように、オブジェクト指向プログラミングとリレーショナルデータベース間のミスマッチで複雑さがあちこちに紛れ込んでしまうことは多々あります
データベースの操作の難しさは本来アプリケーションで解決したい問題と直接関わりがないので、それに振り回されるのは望ましくないです

また、特定のDB(Oracleなど)や特定のORマッパーなどに直接依存すると、ロックインしてそうそう変更できなくなります(バージョンアップも大変です)

これらの問題は、リポジトリを上手く使えば軽減できます

実装面に着目すると例えば、多くの開発者がテーブルの設計が変わってコードを何箇所も修正するような経験があるかと思いますが、リポジトリに操作を集約しておけばリポジトリを使う側の修正はほぼ不要になるので、そのような時でも対応が楽になるでしょう(テストや調査もしやすくなりますね)

ORマッパーなどの外部ライブラリに依存したコードもリポジトリの実装に隠蔽されるので、バージョンアップやライブラリ自体の変更に対応しやすくなります

また、一つのトランザクションで複数のテーブルを正確に更新しなければならない、バグが発生しやすく使う側も注意が求められる複雑な操作も、リポジトリに集約すればだいぶ扱いやすくなります

以上のようなメリットを享受するためにリポジトリパターンは利用されます

実装についてもう少し具体的に言うと、リポジトリインターフェースを作成し、業務ロジックはそれに依存する(呼び出す)。そのインターフェースには、DIコンテナなどを用いて具象リポジトリをインジェクションする。ミドルウェアの変更などあった場合は、それ用の具象クラスを新たに作成しインジェクションする、感じになるでしょう

これらはつまり抽象化によるメリットですので、対象のシステムで管理対象のクラスが増えることと比べて十分なメリットが得られないのであればリポジトリパターンは不要です

小規模なアプリに対しては些か過剰でもあります
ですが、作っているアプリが将来的にどうなるかでも変わってくるので要不要の判断は非常に難しいです

なので、少しでも変更が容易くなるよう自動テストとかCIとかアジャイルとか諸々の手法の出番となるわけですが、本題とズレるのでおしまいにします

結局のところixaさんの開発しているシステムの属性で変わってきますので、上述したようなメリットとデメリットを踏まえた上でどうするのかを判断するしかありません

この記事など参考になるかと思います

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

なぜこの便利なモデルクラスというものが存在するlaravelでリポジトリパターンを実装したがる人がいるのか

特にドメイン駆動設計においては、ビジネスロジックを持つ集約オブジェクト(Entity)に対してリポジトリを定義することで、そのオブジェクトを永続化することが定番のやり方です。

ですので、もしかしたらリポジトリパターンで実装したがる方は、そのような設計方針でコードを書いていらっしゃるのかもしれません。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 87.94%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る