-
service, presenter を利用します
-
ユーザからのリクエストに対し適切なハンドリングを行います
- serviceを利用して業務を遂行します
- presenter へ表示を引き継ぎます
-
ハンドリングのためのデータアクセスを記述すべきではありません
- その判定処理はserviceに記述し、結果を受け取るようにします
- 例)特定のステータスのユーザのみ限定ページへリダイレクトさせる
-
画面表示のためのデータ取得を行うべきではありません
- serviceの利用はデータ更新やハンドリングに必要な判定の依頼に限定すべきです
- 画面に表示したいデータの取得はpresenterに任せます
-
controller, presenter から利用されます
-
model を利用します
-
実装するビジネスにて解決すべき問題を処理するロジックを書きます
- 主にデータ操作に関するロジックが主になります
- その他の操作も実装するかもしれません
-
ユーザ入力やセッションなど、稼動中に生じるデータに直接アクセスしてはいけません
- それはテストを書くことを困難にします
- それらの情報は利用者(controller, presenter)から渡されるようにすべきです
-
serviceから利用されます
-
主にserviceにてDBクラスを利用すると思うので不要?
-
あるとすればModel_Crudを継承したクラスを実装?
-
controller から利用されます
-
service, view を利用します
-
serviceを利用して表示するためのデータを取得します
- 必要な入力値はcontrollerから受け取ります(とすべきか悩む)
-
viewに表示するための処理を記述します
- viewが利用しやすいようにデータを整形したりHTMLを作成したり.
-
viewへ渡す値は極力プリミティブなものにし、オブジェクトなどは渡すべきではありません.
-
controller から利用されます
-
presenter でセットされたデータを表示します
- フォームを作ったりそのバリデーションを行ったりします
- form, validation を持ち、それらが実際の仕事を行います
- fieldset_field オブジェクトを持ち、単一の入力フィールドを表現します
- @see Fieldset - クラス - FuelPHP ドキュメント
- validationはfieldsetがある場合とリンクされます
- フォームはないけどバリデーションは必要という場合は個別に実装します
- @see Validation - クラス - FuelPHP ドキュメント
- クラスではないけど
- 再利用性の高いクラス関数はtraitにして使うようにします.
- ServiceのDB,外部API利用などを想定していますが他にも利用箇所があれば
- @see PHP: トレイト - Manual
- PHPQuickProfiler
- Auth
- RedisDb
- routesをイチイチ設定したくない
- 404, 500 ページのカスタマイズ
- ormは利用しない予定(勉強不足)
- presenterとtemplateの関係をもうちょい
- session を redis へ
- fuelphp で吸収できる?やっぱサーバの設定?
- pagination