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

Bear.SundayとRMパターン

 Bear.SundayとRMパターン

Bear.SundayでなにをResourceにして、なにをResourceにしないのか

またResource以外をどういう構成,設計で実装するべきなのかということをよく悩んでいました

そこで "そこそこよさそうなパターン" としてRMパターンを共有します!

加えて
バリデーションやAPIドキュメントについてもお話します!

hiroki.saito

August 26, 2018
Tweet

More Decks by hiroki.saito

Other Decks in Technology

Transcript

  1. Bear.Sunday と RMパターン

  2. None
  3. アジェンダ - 設計:RMパターン - バリデーション - APIドキュメント

  4. 設計:RMパターン

  5. RMパターン Resource Model Resource リクエストとレスポンスの管理のみ バリデーションやModelの結果によるス テータスコード調整 Model 処理全般

  6. Modelって…?

  7. Model Repository データ取得関連 Resource <-> Repository <-> DataSource というレイヤー構造 Injector

    traitでのセッターインジェクション
  8. Model Manager その他という感じに… あまり考えずにつけてしまいがちだが、いい名前ではない 直下 Sundayの拡張など Sundayの構成と同様なレイヤー構造をつくるのもあり

  9. なぜこういう構成にしたのか

  10. 全てをResourceにするのは難しい

  11. それぞれResourceとして定義できますか? トークのデータを取得する ファイルをアップロードする 音声ファイルを解析する

  12. 余談 app:// page:// 当時はデフォルトで設定されている、 上記以外にResourceを呼び出す拡張方法がわからなかった………

  13. メリット 役割分担が明確で整理,理解しやすい -> 開発速度向上 もしフレームワークを移行してもModel部分は流用可能

  14. デメリット ちょっとMode部分が冗長 特にRepositoryが冗長になりやすい Model配下にResourceの機能が使えない

  15. 改善点 Modelの返り値はオブジェクトにするべきだった 配列も悪くないが、 オブジェクトにすることでの型指定が安心できる

  16. バリデーション

  17. バリデーション 必要だが、冗長になりやすい 結構な手間がかかる 上手に書かないと、可読率が下がる(気がする)

  18. Json-Schemaによるバリデーション Json-Schemaファイル + AOP で完全に”外”に出せる -> 超Happy! ただし あるIDのResourceがユニークであるか, AとBのどちらが必要,両方nullはNGといったことはできない

  19. APIドキュメント

  20. APIドキュメント Swaggerなどは便利だが、 ドキュメントと実際のコードの整合性を保ち続けるのは大変 Json-Schemaでのバリデーション制約 + BEAR.ApiDoc この2つでいい感じに解決!

  21. BEAR.ApiDoc PHPDocとJson-Shcemaを使って APIドキュメントを自動生成してくれる コードを追従することになるので、 引数やバリデーション制約が反映され続ける http://bearsunday.github.io/manuals/1.0/ja/hypermedia-api.html

  22. デモ:APIドキュメント

  23. まとめ

  24. 番外編 Xdebug

  25. 番外編 Deploy

  26. 番外編 Postman

  27. 番外編 Cacheは難しい