Downloaded 14 times
![MVCという概念の無いコード
<?php
// routes.php
Route::get('/top', function ()
{
$mode = Request::get("list_mode");
$list = Master_List::get($mode);
return view("top",["list"=>$list]);
});](https://image.slidesharecdn.com/2016laravel2-160125033631/85/laravel-MVC-19-320.jpg)
![View 層を含むModel
public function getUserJson(){
$data = $this->toArray();
unset($data[“passowrd”]); // パスワードはマスク
return $data;
}
public function getCategory(){
if($this->category){
return “<span class=‘category’>{$this->category}</span>”
}else{
return “<span class=‘default’>未分類</span>”
}
}](https://image.slidesharecdn.com/2016laravel2-160125033631/85/laravel-MVC-42-320.jpg)
![[Laravel] CRUDアプリから一歩踏み出す3つのアプローチ](https://cdn.slidesharecdn.com/ss_thumbnails/crud3-170727044008-thumbnail.jpg?width=640&height=640&fit=bounds)
〜laravel で学ぶ MVC
- 1.
- 2. about me みかかね@mkkn_info #PHPer, フロントエンド #株式会社chatbox 代表 #関西フロントエンドUG代表 関西でWeb制作とかやっています。 03/05にFRONTEND CONFERENCE 2016 開催します。 facebook:後藤知宏 twitter: @mkkn_info
- 3.
- 4.
- 5.
- 6.
- 7. laravelの豊富な機能 • 認証 • キュー管理 •DBマイグレーション • Tack / Schedule管理 • Billing • etc…
- 8.
- 9.
- 10.
- 11.
- 12. Model View Controller Webアプリケーション構築の考え方の1つ ロジックを扱うモデル、見た目に関する処理をするView、 制御系のControllerの３層に分割する。 アプリケーションをModelView Controllerの３階層に分ける 膨大なシステムの分割手法の１つ という、教科書的な話を聞いても 実際の現場ではよくわからない事が多かったり。
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19. MVCという概念の無いコード <?php // routes.php Route::get('/top', function() { $mode = Request::get("list_mode"); $list = Master_List::get($mode); return view("top",["list"=>$list]); });
- 20.
- 21.
- 22.
- 23. ファイル分割のデメリット • 分散するコード • 障害復旧の探索コスト •追加実装時に実装箇所で迷う • etc…
- 24.
- 25.
- 26.
- 27. Controller Model View Request扱う 扱わない 扱わない ロジック 扱わない 扱う 扱わない HTML 扱わない 扱わない 扱う
- 28. Controller の責務 Request (HTTP)を扱う責務 RequestをCに集約する(ロジックがHTTPを意識しない)と、 View層、Model層の再利用性が上がる。 Request= パラメータの処理や、Sessionなど HTTP固有の処理 HTTPがController層に集約されると、 View層、Model層のテスト可能性が高まる。
- 29.
- 30.
- 31.
- 32. Controller(層)ですべきこと • Requestの処理 • Sessionの管理 •バリデーション • エラーハンドリング • ( 諸説あります )
- 33.
- 34.
- 35. Controller 層を含むView <div id=“header”> <?phpif($user = Auth::user()):?> username: <?=$user->name?> <?php endif;?> </div> <?php if($msg = Session::get(“message”)):?> <div class=“alert alert-default”> <?= $msg ?> </div> <?php endif; ?>
- 36. Viewで気をつけること • データの割当は極力変数で割り当てる。 • テンプレート内部で呼び出すのは ステートレスなヘルパー系の関数のみ •ロジック的な複雑な処理は、 ステートレスにして、Modelに追い出す。
- 37. 見た目に特化したViewのメリット • Viewの中にロジックが入らないので コードの見通しが良くなる。 • HTTPレベルの要件に依存しないので、 セッション等リクエスト層での仕様変更で Viewを調査・変更する必要が無くなる。 •リクエストの状態に影響されないので、 Viewを部分的に切り出して転用も楽。
- 38.
- 39.
- 40. Controller 層を含むModel public functionlogin(){ $email = Request::get(“email”); $password = Request::get(“password”); $user = User::where([ “email” => $email ........ public function getUser(){ $id = Session::get(“login_id”); return User::get($id); }
- 41.
- 42. View 層を含むModel public functiongetUserJson(){ $data = $this->toArray(); unset($data[“passowrd”]); // パスワードはマスク return $data; } public function getCategory(){ if($this->category){ return “<span class=‘category’>{$this->category}</span>” }else{ return “<span class=‘default’>未分類</span>” } }
- 43. Modelで気をつけること • Modelの入出力について、特定のケースのみを想定し た書き方をしない。 • 入力：HTTPだけでなくArtisan,Jobなど • 出力：HTMLだけでなくconsole, jsonなど • 単純に引数と戻り値のみ考えれば良い。 • どうしても…という場合にはControllerServiceや ViewModelといった層の導入も考えてみる。
- 44. ロジックに特化したModelのメリット • Modelの責務が明確で仕様変更に強いModel が出来上がる。 • 入出力が明確で、再利用性の高い柔軟なモデ ルが出来上がる。 •再利用性が高く、仕様変更にも強いためテス トを書いても寿命が長く使える。
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.