Bear.SundayとRMパターン

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

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

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

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

Transcript

1. Bear.Sunday と RMパターン
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は難しい