Bear.SundayでなにをResourceにして、なにをResourceにしないのか
またResource以外をどういう構成,設計で実装するべきなのかということをよく悩んでいました
そこで "そこそこよさそうなパターン" としてRMパターンを共有します!
加えて バリデーションやAPIドキュメントについてもお話します!
Bear.SundayとRMパターン
View Slide
アジェンダ- 設計:RMパターン- バリデーション- APIドキュメント
設計:RMパターン
RMパターンResourceModelResourceリクエストとレスポンスの管理のみバリデーションやModelの結果によるステータスコード調整Model処理全般
Modelって…?
ModelRepositoryデータ取得関連Resource <-> Repository <-> DataSource というレイヤー構造Injectortraitでのセッターインジェクション
ModelManagerその他という感じに…あまり考えずにつけてしまいがちだが、いい名前ではない直下Sundayの拡張などSundayの構成と同様なレイヤー構造をつくるのもあり
なぜこういう構成にしたのか
全てをResourceにするのは難しい
それぞれResourceとして定義できますか?トークのデータを取得するファイルをアップロードする音声ファイルを解析する
余談app://page://当時はデフォルトで設定されている、上記以外にResourceを呼び出す拡張方法がわからなかった………
メリット役割分担が明確で整理,理解しやすい-> 開発速度向上もしフレームワークを移行してもModel部分は流用可能
デメリットちょっとMode部分が冗長特にRepositoryが冗長になりやすいModel配下にResourceの機能が使えない
改善点Modelの返り値はオブジェクトにするべきだった配列も悪くないが、オブジェクトにすることでの型指定が安心できる
バリデーション
バリデーション必要だが、冗長になりやすい結構な手間がかかる上手に書かないと、可読率が下がる(気がする)
Json-SchemaによるバリデーションJson-Schemaファイル + AOP で完全に”外”に出せる-> 超Happy!ただしあるIDのResourceがユニークであるか,AとBのどちらが必要,両方nullはNGといったことはできない
APIドキュメント
APIドキュメントSwaggerなどは便利だが、ドキュメントと実際のコードの整合性を保ち続けるのは大変Json-Schemaでのバリデーション制約 + BEAR.ApiDocこの2つでいい感じに解決!
BEAR.ApiDocPHPDocとJson-Shcemaを使ってAPIドキュメントを自動生成してくれるコードを追従することになるので、引数やバリデーション制約が反映され続けるhttp://bearsunday.github.io/manuals/1.0/ja/hypermedia-api.html
デモ:APIドキュメント
まとめ
番外編 Xdebug
番外編 Deploy
番外編 Postman
番外編 Cacheは難しい