Bear.SundayとRMパターン

Slide 1

Slide 1 text

Bear.Sunday と RMパターン

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

設計:RMパターン

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Modelって…？

Slide 7

Slide 7 text

Model Repository データ取得関連 Resource <-> Repository <-> DataSource というレイヤー構造 Injector traitでのセッターインジェクション

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

バリデーション

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

APIドキュメント

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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