Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ServiceとRepository

 ServiceとRepository

2017/4/12 関西PHPユーザーズグループの勉強会での登壇資料です。

ServiceとRepositoryについて自分なりに解釈してみたことをまとめました。

C385e96e5ddd25faba59e3e14fc3e019?s=128

ショウノシオリ

April 12, 2017
Tweet

More Decks by ショウノシオリ

Other Decks in Programming

Transcript

  1. PHP勉強会 ServiceとRepository

  2. 自己紹介 ショウノシオリ ◦ 株式会社chatbox ◦ エンジニア ◦ @shoshoでQiita記事 書いてます ◦

    Laravel と日々格闘
  3. 最近開発したもので出てきた Service と Repository がよくわからなかったので勉強してみました

  4. 開発したもの ▷ Laravel 5.4 ▷ ECサイト(管理画面のみ) ▷ フロントは他の会社 ▷ コードの設計は完了済みだった

  5. 開発に使う主なもの ▷ View ▷ Route ▷ Controller

  6. と ▷ Service ▷ Repository ▷ Eloquent

  7. DBにアクセスするまでの流れ Controller Service Repository Eloquent DB

  8. DBまわりがなぜ こんなに細かく分けられているんだろう?

  9. Service と Repository は必要なのか?

  10. DBにアクセスするまでの流れが Controller Service Repository Eloquent DB だとすると

  11. 2つの問題点 ▷ DBの設計が変わったときに、 Eloquentを 使っているコントローラ全てを修正する必要 が出て来る ◦ めんどう ◦ 大変 ▷

    フロントでも同じDB操作をすることがある のに、別々でつくるのはもったいない ◦ ユーザー情報の取得、とか
  12. この2つを解決するのが Service と Repository

  13. DBの設計が変わったときに、Eloquentを使っ ているコントローラ全てを修正する必要が出て 来る 問題

  14. Repositoryが解決 ▷ Eloquentを操作する唯一のクラス。ここか ら先はEloquentではなくEntityとしてデータ を持ち回すようにしている。 ◦ DB変更に伴うEloquentの修正が与える 影響はリポジトリ内に収まる ◦ 修正箇所を見つけやすい

    ◦ 修正する場所も少なくて済む
  15. フロントでも同じDB操作をすることがあるの に、別々でつくるのはもったいない 問題

  16. Serviceが解決 ▷ 「ユーザー情報を取得したい」といった具体 的な要求に対する処理を提供するクラス。 ◦ 再利用できる ◦ 処理自体を固めることになるので、画面 の仕様変更などに強くなる

  17. なので以下のような役割分担になっている のかな、と

  18. Controller Service Repository Eloquent DB リクエストの受取と 結果を返す、だけ 要求に対するものを 提供するクラス Eloquentを管理する

    唯一のクラス DBを操作する
  19. このように 関心事 = ドメイン を中心に開発をすすめる方法が ドメイン駆動設計(DDD) 的な?

  20. なぜこんなに細かくわけられているんだろう? の答えとしては

  21. ▷ フロントとの開発をみこしたものだから ▷ 各クラスにしっかり役割分担しておくことで 修正しやすくするため かなぁと思いました

  22. つくる立場であっても 少しずつ設計思想についても学んでいきたいと 思います

  23. Thanks! Any questions?